Re: Browsers in D
On Wednesday, 20 December 2023 at 00:07:44 UTC, Adam D Ruppe wrote: On Tuesday, 19 December 2023 at 23:40:48 UTC, Antonio wrote: [...] Oh, I'm old enough to remember the Chrome auto-update that broke standard HTML links! It was such a pain supporting it in the first few years, while IE and Firefox were both working pretty well at the time. But, like I just said in the other post, Firefox has near-zero support for being embedded in other applications. If you know of a way that we could reasonably use from D, let me know, but the only time I've seen an embedded Gecko is actually in the Wine project... and this had no other way to access it that I could find. [...] Mozilla has closed *dozens* of bugs that affect me directly as WONTFIX, including fairly simple to fix regressions. That's why I can't use it anymore. [...] If you wanna work on my other engine to bring it up to spec, feel free lol, but the screenshots speak to the functionality gap... When I was the CTO of my previous company, we embedded Gecko into a custom C++ GUI framework, to allow ALS people browse the web using gazes as an input method: it was a real pain ...
Re: ImportC has improved macro support
On Friday, 8 December 2023 at 05:17:30 UTC, Ki Rill wrote:
On Wednesday, 6 December 2023 at 19:59:54 UTC, Walter Bright
wrote:
Macros with the pattern:
#define BOO ( expression )
are now translated to:
auto BOO()() { return expression; }
and are available for importing!
This is amazing! It should solve the disappearing of enum-like
definitions in code. I encountered this in Raylib. It has
colors defined as macros:
```c
#define WHITE (Color){255, 255, 255, 255}
```
I preprocessed the file and all color definitions were gone. I
had to redefine them manually.
Nuklear does the same too for their Flags.
Same situation here, with RayLib!
I really really like the way importC is improving, kudos to
Walter!
/Paolo
Re: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 18:01:36 UTC, Guillaume Piolat wrote: On Tuesday, 14 November 2023 at 15:05:34 UTC, Steven Schveighoffer wrote: [...] +1 and only the introduction of edition has this problem, it's a one time cost for the ecosystem. +1 too
Re: Blog post: How we are using D to develop Aspect from the ground up
On Monday, 23 October 2023 at 19:02:46 UTC, Sönke Ludwig wrote: I've written up an article that showcases how we use D in production and how that benefits us in unique ways. The format of a single blog post limits the detail into which it can go, given the broad scope, so this is probably not super interesting to long time D users, but maybe it sparks some interest for people who just loosely follow the language. When I get some more time, I'd like to expand on a few of the topics. Any suggestions of what might be especially interesting/impactful are of course welcome! Link: https://aspect.bildhuus.com/blog/posts/how-we-are-using-d-from-the-ground-up " .. here is hope that the language will eventually find its way back to the really clean appearance that it once had .. " /P
Re: reggae v0.10.0 - The meta build system just got better
On Wednesday, 20 September 2023 at 21:19:22 UTC, Atila Neves wrote: Then there's the language: I'd rather use D or Python. Someone, somewhere, almost 20 years ago ... https://forum.dlang.org/post/40bb3d47.9030...@inwind.it In the D land, everything always changes, to never really change ... it's really a big wheel, or better a pendulum! :-P /Paolo
Re: LDC 1.34.0
On Monday, 28 August 2023 at 02:02:07 UTC, ryuukk_ wrote: ARM support for DMD would help making it future proof +1
Re: Evolving the D Language
On Friday, 7 July 2023 at 03:06:28 UTC, Walter Bright wrote: As time moves on, the D language has to evolve as well. What do we do with obsolete and/or problem-causing, legacy features? [...] I respectfully disagree, and prefer to keep going on with the current deprecation and cleanup policy: Scott Meyers' DConf 2014 keynote all the way down. On the other side, there's no problem at all in resurrect dead features, when living without them proved to be a pain (I agree with Rikki, hex strings). /Paolo
Re: New beginnings - looking for part-time D programming help
On Friday, 24 March 2023 at 09:01:21 UTC, Sergey wrote: On Friday, 24 March 2023 at 07:54:06 UTC, Monkyyy wrote: On Thursday, 23 March 2023 at 16:02:46 UTC, Laeeth Isharc wrote: Hi. For those that didn't hear, I resigned from Symmetry in September and my last day was a couple of weeks back. [...] "Not hedge fund" and "scripting" doesn't seem like enough of a job description to me My guess it is something related to context reconstruction :) When someone said something with quite limited words and sentences - he has a lot more context in his mind. Not always this context is the same for other people. Based on description this script could help to align the same context of conversation. Just guessing :) Btw is any LLM embedding available in open source? Sort of ... you need LLaMA 7B and to train it, but they are trying to have permissions to release the weights also. https://crfm.stanford.edu/2023/03/13/alpaca.html
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 20:41:17 UTC, Andrea Fontana wrote: On Tuesday, 10 May 2022 at 20:13:45 UTC, Paolo Invernizzi wrote: Sinceramente non ricordo di averlo scritto, ma alla mia eta ... probabilmente dimentico qualcosa ... comunque piacere! E' bello vedere altri italiani apprezzare questo magnifico linguaggio! (Frankly speaking, I don't remember to have written that, but hey, I'm getting old ... probably I'm forgetting something ... anyway nice to meet you! It's great to see Italians here enjoying this great programming language!) I wonder if you're making a fool of me. Or maybe it's me who is getting old. I'm pretty sure that there's a user here with a really Italian name who was born somewhere in South America. Andrea Here I am ... Milanese: https://www.deepglance.com/about /Paolo
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 19:55:32 UTC, Andrea Fontana wrote: On Tuesday, 10 May 2022 at 19:50:08 UTC, Paolo Invernizzi wrote: Concordo ... (I agree!) :-P Wait, you have always said you're not Italian. Have you changed your mind? Andrea Sinceramente non ricordo di averlo scritto, ma alla mia eta ... probabilmente dimentico qualcosa ... comunque piacere! E' bello vedere altri italiani apprezzare questo magnifico linguaggio! (Frankly speaking, I don't remember to have written that, but hey, I'm getting old ... probably I'm forgetting something ... anyway nice to meet you! It's great to see Italians here enjoying this great programming language!)
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 16:05:11 UTC, Andrea Fontana wrote: On Tuesday, 10 May 2022 at 15:35:35 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 10 May 2022 at 15:27:48 UTC, Andrea Fontana wrote: Indeed the "-ino" suffix in "serverino" stands for "small" in italian. :) Bambino > bambinello? So, the embedded-version could be «serverinello»? :O) Oh, italian is full of suffixes. -ello means a slightly different thing. It's small but sounds like a bit pejorative. -ino in bambino is not (anymore) a suffix, anyway. Andrea Concordo ... (I agree!) :-P
Re: D Language Foundation Monthly Meeting for February 2022
On Friday, 4 March 2022 at 07:10:05 UTC, Mike Parker wrote: On Friday, 4 March 2022 at 06:00:06 UTC, Arun wrote: Just curious if we looked at GitLab as an alternative to both GitHub and Bugzilla. We're happy on GitHub and have no plans to move to GitLab. Quoting Vladimir, "On the other hand with Bugzilla we are fully in control and own our data, which allows doing a few things not possible with GitHub". GitLab il free software, available and installable on a private server, like Bugzilla, so both the chicken and the eggs. But I fully understand that a migration to GilHub is just fine right now.
Re: Teaching D at a Russian University
On Sunday, 20 February 2022 at 04:38:46 UTC, matheus wrote: On Sunday, 20 February 2022 at 03:44:42 UTC, Paul Backus wrote: Yes, this is a perfectly correct use of "for" as a coordinating conjunction. [1] It may come across as a bit formal or old-fashioned, though—in normal speech, you'd usually use "since". [1] https://writing.wisc.edu/handbook/grammarpunct/coordconj/ Interesting, since English is not my first language, if in that sentence instead of "for" there was the word "since", I wouldn't have been bothered, but since it was the first time I saw the usage of "for" in that way, I found awkward. After that I even look into a translator which gave the same translation with "since" and "for" in that sentence. Well living and learning. :) Matheus. And this is 'Chaos' for us, poor ESL people ... http://ncf.idallen.com/english.html :-P
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Sunday, 6 February 2022 at 15:17:35 UTC, Paul Backus wrote: On Sunday, 6 February 2022 at 14:44:40 UTC, Ola Fosheim Grøstad wrote: On Sunday, 6 February 2022 at 13:33:53 UTC, Paul Backus wrote: @mustUse is a user-defined attribute, and the official style guide says that names of UDAs should be camelCased: It is kinda confusing to call it a user-defined attribute if it is recognized by the compiler. Compiler-recognized UDAs are an established feature of D. See [`core.attribute`][1] for more examples. I dislike the camel case as well, and the name is less clear than "nodiscard" in my opinion. I suppose you'll have to take that up with Walter, since he's the one who vetoed "nodiscard". To be honest, though, I can see where he's coming from. When writing DIP 1038, I made a conscious effort to avoid using the term "non-`@nodiscard`", due to the double negative. With a positively-phrased name like `@mustUse`, that problem disappears. [1]: https://druntime.dpldocs.info/core.attribute.html @hold (or @held) ? donwannaopenacanofworms ... my last post really :-P (btw, It's a great companion for sumtype! thank you again!)
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Sunday, 6 February 2022 at 14:56:42 UTC, Paul Backus wrote:
On Sunday, 6 February 2022 at 14:32:31 UTC, Paolo Invernizzi
wrote:
While I like a lot and welcome the addition of this attribute
(so thank you!), I humbly ask to reconsider using the full
lowercase alternative instead of camel case.
Let's conform with the other built-in attributes listed into
the specs of the language, avoiding what would be another
special case to remember.
There is precedent for compiler-recognized UDAs using camelCase
in core.attribute.gnuAbiTag [1], as well as the various
LDC-specific attributes [2]. So no matter what I choose here,
it will be inconsistent with something.
If you strongly prefer the lower-case version, you can always
rename it in your own code:
import core.attribute: mustuse = mustUse;
@mustuse struct MyStruct
{
// ...
}
[1]: https://druntime.dpldocs.info/core.attribute.gnuAbiTag.html
[2]:
https://wiki.dlang.org/LDC-specific_language_changes#Attributes
That's fine, I will not insist more, hoping not to see in the
future it extended as a function attribute ... you know ...
int foo() @nogc @safe @mustUse etc etc ...
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Sunday, 6 February 2022 at 14:00:15 UTC, Paul Backus wrote: On Sunday, 6 February 2022 at 13:40:00 UTC, Paolo Invernizzi wrote: On Sunday, 6 February 2022 at 13:33:53 UTC, Paul Backus wrote: @mustUse is a user-defined attribute, and the official style guide says that names of UDAs should be camelCased: https://dlang.org/dstyle.html#naming_udas ... This matches conventions of the built in attributes like @safe, __@nogc__ ... Presumably this is referring to the part about the first letter being lower-case, since the built-in attributes are quite obviously not camelCased. While I like a lot and welcome the addition of this attribute (so thank you!), I humbly ask to reconsider using the full lowercase alternative instead of camel case. Let's conform with the other built-in attributes listed into the specs of the language, avoiding what would be another special case to remember.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Sunday, 6 February 2022 at 13:33:53 UTC, Paul Backus wrote: On Sunday, 6 February 2022 at 10:55:20 UTC, Daniel N wrote: Guess I'm way too late, I just find it very strange you settled on mixedCase, it's not used for anything else. (nothrow @nogc). I also don't agree with the motivation that @use is hard to search for because @ is an unusual symbol. @mustUse is a user-defined attribute, and the official style guide says that names of UDAs should be camelCased: https://dlang.org/dstyle.html#naming_udas "Hard to search for" in this context means "hard to Google for", not "hard to grep for". Search engines tend to ignore symbols like @. ... This matches conventions of the built in attributes like @safe, __@nogc__ ...
Re: Please Congratulate My New Assistant
On Tuesday, 19 January 2021 at 00:12:49 UTC, Max Haughton wrote: The second category is a bit looser, as there are some things I'd like to do that come under the community relations remit that aren't as structured - e.g. I am very interested in getting a proper working group together to try and iterate through designs properly rather than incremental DIPs. That would be great!
Re: Release Candidate [was: Re: Beta 2.095.0]
On Wednesday, 30 December 2020 at 14:43:53 UTC, Mathias LANG wrote: On Wednesday, 30 December 2020 at 14:23:39 UTC, Paolo Invernizzi wrote: On Wednesday, 30 December 2020 at 10:51:38 UTC, Martin Nowak wrote: On Sunday, 20 December 2020 at 13:21:46 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.095.0 release, ♥ to the 61 contributors. The release candidate for 2.095.0 is live now. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.095.0.html As usual please report any bugs at https://issues.dlang.org -Martin Thank you Mathias for commit 5f701dc! Unfortunately it doesn't fix the exact case you found, it was a byproduct of working on your test case. And I don't think I'll have time to get to it before the release (which is scheduled January 1st). Don't worry, I've just tried a fast build and it seems far better than before!
Re: Release Candidate [was: Re: Beta 2.095.0]
On Wednesday, 30 December 2020 at 10:51:38 UTC, Martin Nowak wrote: On Sunday, 20 December 2020 at 13:21:46 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.095.0 release, ♥ to the 61 contributors. The release candidate for 2.095.0 is live now. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.095.0.html As usual please report any bugs at https://issues.dlang.org -Martin Thank you Mathias for commit 5f701dc!
Re: Beta 2.095.0
On Tuesday, 29 December 2020 at 10:48:55 UTC, Paolo Invernizzi
wrote:
On Thursday, 24 December 2020 at 23:14:16 UTC, Mathias LANG
wrote:
[...]
Mathias, reduced test case below (dustmined), thank you!
[...]
Manually reduced to:
---
import std.typecons : Nullable;
import std.array : array;
class PGResultSet
{
bool empty = true;
void popFront() {}
Foo front;
}
struct Foo {
Nullable!long sessionStartedAtMs;
}
void foo() {
auto rset = new PGResultSet;
rset.array;
}
---
Re: Beta 2.095.0
On Thursday, 24 December 2020 at 23:14:16 UTC, Mathias LANG wrote:
On Thursday, 24 December 2020 at 21:59:31 UTC, Paolo Invernizzi
wrote:
My point is that the result without -de is
[...]
Which unfortunately is pretty useless in my case ...
Could you point me towards the code that triggers this ?
Mathias, reduced test case below (dustmined), thank you!
---
/Users/pinver/dlang/dmd-2.095.0-beta.1/osx/bin/dmd -c -o-
-J/Users/pinver/Lembas -vcolumns -color=on -Isrc -debug -unittest
/Users/pinver/Tmp/dustmite/testing.reduced/src/fieldmanager.d ||
true <
/Users/pinver/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/traits.d(3727,61):
Deprecation: function std.typecons.Nullable!long.Nullable.get_ is deprecated -
Implicit conversion with alias Nullable.get this will be removed after 2.096.
Please use .get explicitly.
---
import std.typecons : Nullable;
import std.array : array;
struct DBRow(Specs...)
{
alias Specs[] T;
T base;
}
class PGConnection
{
PGResultSet!Specs executeQuery(Specs)(string )
{
scope cmd = new PGCommand(this);
return cmd.executeQuery!Specs;
}
auto pgCommand(string ) {
return new PGCommand(this);
}
}
class PGCommand
{
PGConnection conn;
string preparedName;
this(PGConnection ){
}
PGResultSet!Specs executeQuery(Specs)()
{
return conn.executeQuery!Specs(preparedName);
}
}
class PGResultSet(Specs)
{
alias DBRow!Specs Row;
bool empty = true;
void popFront()
{
}
Row front()
{ return Row.init;
}
}
void importPanoptesFixations(short legId, DbModel dbModel)
{
queryAsArray(dbModel.conn, legId);
}
struct DbModel
{
PGConnection conn;
}
struct Foo {
Nullable!long sessionStartedAtMs;
}
auto queryAsArray(Conn)(Conn conn, short ) {
auto comm = conn.pgCommand(`select * from foo`);
auto rset = comm.executeQuery!Foo;
rset.array;
}
---
Re: Beta 2.095.0
On Thursday, 24 December 2020 at 18:05:30 UTC, Mathias LANG wrote:
On Thursday, 24 December 2020 at 11:38:11 UTC, Paolo Invernizzi
wrote:
The point is that the deprecation is coming from an external
library, it would be great to have the precise instantiation
point in that source code, so I was wondering if that dmd
improvement [1] should print a more detailed trace.
[1]
https://dlang.org/changelog/2.095.0.html#deprecation-context
It does print a detailed stack trace (up to the first symbol
that is not a template) if you don't use `-de`. If you use
`-de`, since the checks in Phobos are
`is(typeof(n.toString()))` or `__traits(compiles,
n.toString())`, then it just changes whether or not the code
compiles, and as a result changes the output of the program. A
trivial example:
```
import std.stdio, std.typecons;
struct Foo {
deprecated string toString() const { return "Oops"; }
}
void main () { writefln("%s", Foo.init); }
```
Will print, with v2.094.2 or before (dmd -run):
```
/usr/local/opt/dmd/include/dlang/dmd/std/format.d(3921):
Deprecation: function foo.Foo.toString is deprecated
/usr/local/opt/dmd/include/dlang/dmd/std/format.d(4053):
Deprecation: function foo.Foo.toString is deprecated
Oops
```
Not great. If you use `dmd -de -run`, you'll get:
```
Foo()
```
Notice the deprecations are gone, but so is the usage of the
`toString` method. Using DMD v2.095.0-beta.1 with `-de` should
give you the same output, but without `-de`:
```
% ~/dlang/dmd-2.095.0-beta.1/osx/bin/dmd -run foo.d
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(3921):
Deprecation: function foo.Foo.toString is deprecated
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(4420):
instantiated from here: hasToString!(Foo, char)
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(4053):
Deprecation: function foo.Foo.toString is deprecated
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(4430):
instantiated from here: formatObject!(LockingTextWriter, Foo, char)
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(1875):
instantiated from here: formatValueImpl!(LockingTextWriter, Foo, char)
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(576):
instantiated from here: formatValue!(LockingTextWriter, Foo, char)
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/stdio.d(1661):
... (1 instantiations, -v to show) ...
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/stdio.d(4271):
instantiated from here: writefln!(char, Foo)
foo.d(5):instantiated from here: writefln!(char, Foo)
Oops
```
So the feature works as intended, however `-de` is a dangerous
trap, as it changes what is instantiated.
Thanks Matias,
My point is that the result without -de is
---
/Users/pinver/dlang/dmd-2.095.0-beta.1/osx/bin/dmd -i -g -debug
src/foo.d
/Users/pinver/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/traits.d(3727):
Deprecation: function std.typecons.Nullable!long.Nullable.get_ is deprecated -
Implicit conversion with alias Nullable.get this will be removed after 2.096.
Please use .get explicitly.
/Users/pinver/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/traits.d(3727):
Deprecation: function std.typecons.Nullable!short.Nullable.get_ is deprecated
- Implicit conversion with alias Nullable.get this will be removed after 2.096.
Please use .get explicitly.
---
Which unfortunately is pretty useless in my case ...
Re: Beta 2.095.0
On Thursday, 24 December 2020 at 11:05:14 UTC, Mathias LANG wrote: On Wednesday, 23 December 2020 at 15:38:17 UTC, Steven Schveighoffer wrote: What is happening is that some speculative compilation is checking something via the get function. It might not make a difference, but the error message is useless (who knows where that traits call is triggered). FYI, v2.095.0 *should* print the instantiation trace, so you can actually track down where it comes from. And the reason DMD now shows the trace is exactly because of this deprecation. The point is that the deprecation is coming from an external library, it would be great to have the precise instantiation point in that source code, so I was wondering if that dmd improvement [1] should print a more detailed trace. [1] https://dlang.org/changelog/2.095.0.html#deprecation-context
Re: Printing shortest decimal form of floating point number with Mir
On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote: On Wednesday, 23 December 2020 at 17:22:28 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 23 December 2020 at 17:08:26 UTC, 9il wrote: [...] Yes, if something is perceived as bug it becomes a burden to remember that it is isn't. Not sure why anyone resist this improvement. Hm, he seems to be a compiler consultant now, but no longer interested in D? Hi is disappeared from the Dlang after that. Maybe the DIP should have pushed harder on what other languages support (might be viewed as a stronger political argument). Have you read the DMD PR thread (not the DIP itself)? It was a mockery executed by Atila accompanied by silent Walter's and Andrei's ignoring. I know Atila in person. However, it doesn't really matter if Atila really didn't understand the DIP reasons or it was a real mockery. The fact that this behavior including real or seeming mockery and real ignoring is a red flag for any professional cooperation. Atila had been already declared as "new Andrei". Which was noted right in the DIP to define Atila's privileges to make decisions. https://github.com/dlang/dmd/pull/9778#issuecomment-498700369 [...] I don't use tensors much, how does it help zipping? I sometimes wonder if linalg primitives should be builtin too. Seems like that could allow for better compiler optimization. Franky speaking, I don't see any mockery, but I'm not a native English speaker, so I could have missed it. Said that, if you really see value in the DIP, can I suggest to keep explaining your reason? I'm totally sure everybody here is engaged in discussion with the goal to understand. ... my 2c
Re: Beta 2.095.0
On Wednesday, 23 December 2020 at 15:38:17 UTC, Steven Schveighoffer wrote: On 12/23/20 9:42 AM, Paolo Invernizzi wrote: [...] So, this is a constant problem since this deprecation was introduced. [...] Thanks Steve, as usual, a perfect explanation ...
Re: Beta 2.095.0
On Wednesday, 23 December 2020 at 14:41:05 UTC, Paolo Invernizzi wrote: BTW, turning the deprecations from warnings to errors seems not to work (nothing is printed) --- /Users/pinver/dlang/dmd-2.095.0-beta.1/osx/bin/dmd -i -g -debug src/foo.d --- Thank you for your job! sorry, I mean: `/Users/pinver/dlang/dmd-2.095.0-beta.1/osx/bin/dmd -de -i -g -debug src/foo.d`
Re: Beta 2.095.0
On Sunday, 20 December 2020 at 13:21:46 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.095.0 release, ♥ to the 61 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.095.0.html As usual please report any bugs at https://issues.dlang.org -Martin Thank you Martin, Just to be sure, is that expected behaviour? Or should I expect to have the a more precise instantiation point? --- /Users/pinver/dlang/dmd-2.095.0-beta.1/osx/bin/dmd -i -g -debug src/foo.d /Users/pinver/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/traits.d(3727): Deprecation: function std.typecons.Nullable!long.Nullable.get_ is deprecated - Implicit conversion with alias Nullable.get this will be removed after 2.096. Please use .get explicitly. /Users/pinver/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/traits.d(3727): Deprecation: function std.typecons.Nullable!short.Nullable.get_ is deprecated - Implicit conversion with alias Nullable.get this will be removed after 2.096. Please use .get explicitly. --- BTW, turning the deprecations from warnings to errors seems not to work (nothing is printed) --- /Users/pinver/dlang/dmd-2.095.0-beta.1/osx/bin/dmd -i -g -debug src/foo.d --- Thank you for your job!
Re: Visual D 1.0.0 released
On Friday, 10 July 2020 at 07:32:42 UTC, Jacob Carlborg wrote: Yeah, VisualD has a huge advantage since it's now using the DMD frontend for these things. For example, DCD does not support UFCS, which is really annoying. That is the most annoying thing for sure: It would be great to have the semantic engine of visual-d exposed via a language server ... /P
Re: DIP1028 - Rationale for accepting as is
On Sunday, 24 May 2020 at 05:43:45 UTC, Timon Gehr wrote: @safe is advertised to give mechanical guarantees, where @trusted is a way for programmers to take responsibility for parts of the code. It is not advertised to be an unsound linter with pseudo-pragmatic trade-offs and implicit false negatives. And turns back to my previous question, that Walter (or Atila) never replied: what I need to reply back to customers asking us about @safe. @safe is for mechanical check or not? An official and public declaration please. /P
Re: DIP1028 - Rationale for accepting as is
On Saturday, 23 May 2020 at 10:55:40 UTC, Dukc wrote: When I look my own code that uses the Nuklear GUI library, written in C, it's all `@system`. I have not had the time to make `@trusted` wrappers over the BindBC-nuklear API, so I did what tends to occur to us as the next best thing: resign and make the whole client code `@system`. I really don't understand, there's no "maybe" memory safety: if there's no time to spend for memory safety in a project, why care? Just making `@trusted` wrappers over BindBC-nuklear seemed to me as inresponsible use of the attribute. And reading this theard, it would seem like most of you would agree. I disagree: if you *really* want to use @safe in the rest of the codebase, just mark the binding as trusted, raising your hand towards reviewers (or everybody is interested in checking the memory safety of the project codebase), writing in the comment that "you" have decided to spend no time in a proper wrapping, and the motivations. Let the reviewers and the other guys out there just decide what to do with your codebase. But when I think it, what I have accomplised from avoiding that antipattern? The only difference is, that if my D code does something `@system`, it'll remain under the radar. So I'm worse off than had I submitted to the antipattern! It's not an anti pattern, it clearly show your motivation, that's all about @trusted. May also write a big *disclaimer* in the README pointing to the pitfalls
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 17:54:26 UTC, Atila Neves wrote: On Friday, 22 May 2020 at 17:41:38 UTC, Steven Schveighoffer And so, you are free to pepper your @safe code with dangling pointers. Sure, you can claim that the C++ library didn't "corrupt your code", which is the case for ALL libraries if you use them properly. You did it, you created a dangling pointer, not the library. Right. And the point I was trying to make wasn't "look at what I did, it's cool". No, what I did was dumb. So dumb it took you no time at all to point out one of my mistakes. My point is that the result of making declarations implicity @system instead of @safe would make people just slap @safe on them without really thinking about it to get their code to compile. Like I did. So force people to slap @trusted instead, via compiler complains, not @safe, and reviewers will catch the laziness: why this is worst that what you picture?
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 17:07:37 UTC, Atila Neves wrote: And so I was convinced that everything being @safe is actually ok, especially because in real life, most C/C++ APIs aren't going to secretly corrupt your code. Uh? There's plenty of C/C++ code out there with api that when "used in the wrong way" will corrupt memory. That's the _essence_ of @trusted code, the _programmer_ need to _correctly_ handle the usage, because the compiler can't do that job alone.
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote: I have made these points before, but I'll summarize them here for convenient referral. [...] Thank's for the reasoning, that should be added to the DIP acceptance since the beginning. Stated that we need to live with that, I'm asking you a simple question: What's the "official" definition of the @safe advantages that D offers as a language? Sometime we need to explain that to customers asking for details about the code we wrote for them. I would love to have a good insight detailing the promises that the language is committed to hold, maybe trying to give me a vision on the future ... since from now on I will stop using "mechanical verification" at all as selling argument.
Re: DLS deprecation
On Tuesday, 7 April 2020 at 19:12:49 UTC, Laurent Tréguier wrote: I started working on this project to make it more comfortable to write D back in 2017, published a VSCode extension a couple months later, and continued working on it throughout 2018. In 2019 however, I slowed down, and eventually, stopped working on it. It was fun, and kept me well occupied for quite some time; but I have been working on something else since April of last year, and since I don't have any use for D in it, I am not taking time to do anything with DLS. So today, I am deprecating DLS, along with its editor extensions. If anyone was using them, be advised that they will not have any update or support from now on. Webfreak is still working on code-d/serve-d from what I gather, so hopefully, the handful of people who could be using DLS on VSCode can use it instead. *sigh* So Long, and Thanks for All the Fish, Laurent!
Re: DConf 2020 Canceled
On Sunday, 8 March 2020 at 03:56:35 UTC, Era Scarecrow wrote: From what i've researched, it's more or less the flu... a somewhat more contagious, over-hyped, genetically modified, potentially respiratory infection cold/flu; And likely a tool by government(s) to force unwanted policies down our throats like Martial Law, restriction of travel, Mandatory Vaccines and/or micro-chipping. As well as the government had it since 2015 in certain labs thus more than likely there's already a vaccine. I'm writing this note from Italy, and specifically from Milano, and I've only one request: please stop. Let's stay talking only about the marvellous D language.
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 09:30:30 UTC, Walter Bright wrote: On 2/27/2020 12:27 AM, Petar Kirov [ZombineDev] wrote: I'm well aware that allocation is inevitable if we want this behavior. My argument is that this behavior is so ubiquitous that not following it would be surprising to much more people, than if D didn't follow C's Usual Arithmetic Conversions rules. For example, Rust not following those conversion rules is considered a good thing, Rust does not follow C syntax at all, so nobody will reasonably expect it to have C semantics. D does follow it, it's a feature, so people will have expectations. As shown, string interpolation in other languages (not only 'stript', as you wrote) has a so well established way of performing it that everybody will reasonably expect D to behave the same. Said that, better having no string interpolation at all in D, if the introduced feature is not at least comparable with the solution that the others out there are using: no surprise behaviour, please! and there it is. But having it generate a GC allocated string is not so easy to unwind, i.e. it'll be useless with printf and generate unacceptable garbage with writefln. The extra string will always make it slow. Essentially, it'll be crippled. Making D behave like a scripting language will yield scripting performance. It seems that the other compiled languages doing it in that way have raised no concerns at all on the above matters
Re: dud: A dub replacement
On Wednesday, 20 November 2019 at 16:29:20 UTC, Rumbu wrote: When a function signature looks like this ElementEncodingType!(ElementType!RoR)[] join(RoR, R)(RoR ror, scope R sep) if (isInputRange!RoR && isInputRange!(Unqual!(ElementType!RoR)) && isInputRange!R && is(Unqual!(ElementType!(ElementType!RoR)) == Unqual!(ElementType!R))) or like this: E[] replaceFirst(E, R1, R2)(E[] subject, R1 from, R2 to) if (isDynamicArray!(E[]) && isForwardRange!R1 && is(typeof(appender!(E[])().put(from[0..1]))) && isForwardRange!R2 && is(typeof(appender!(E[])().put(to[0..1]; it's understandable why documentation is mandatory. That's true, Rumbu! And despite that, it's always marvel me the fact that I can simply read the above and actually "understand it"! It's some kind of magic, but maybe it's simply why I'm forced to read too much C++ recently... :-P PS ... the most difficult part for a beginner maybe is the historical "is(typeof( ... bla bla ...)"
Re: dud: A dub replacement
On Monday, 18 November 2019 at 15:35:12 UTC, Joseph Rushton Wakeling wrote: On Monday, 18 November 2019 at 13:19:12 UTC, Paolo Invernizzi wrote: Closing this kind of discussions and letting anyone to choose "tabs or spaces" is a constructive solution, I think. It is quite extraordinary how readily folks fall to arguing over what the config format should be, rather than what the app should actually be able to do. :-\ Exactly, that's why I love pragmatism: let's dud emit the ones that are outdated, automatically. Everyone can choose, work and update or the format he prefers, without impacting other people choices, and the discussion can move forward to something more interesting ... my 2 cents, at least ...
Re: dud: A dub replacement
On Monday, 18 November 2019 at 10:44:18 UTC, Russel Winder wrote: On Mon, 2019-11-18 at 09:53 +, Paolo Invernizzi via Digitalmars-d-announce wrote: […] A win-win move would be to have dud emit the other formats automatically as part of the compilation procedure, so to have always all of them present and synced on the content. Why? In fact, why even think of doing this at all? There should be one and only one human written configuration file for a build and it should be in a notation suitable for being written by humans. It shouldn't be too much difficult, and maybe it's a cleaver way to move on from discussions about different formats. Again why? It seems like a pointless overhead that achieves nothing constructive. Closing this kind of discussions and letting anyone to choose "tabs or spaces" is a constructive solution, I think. That's the whole point of a win-win solution, anyone has a gain, the JSON party and the SDL party. But, hey, as someone has to implement that, feel free to simply ignore my opinion ...
Re: dud: A dub replacement
On Monday, 18 November 2019 at 09:42:16 UTC, Russel Winder wrote: On Mon, 2019-11-18 at 09:31 +, Sebastiaan Koppe via Digitalmars-d-announce wrote: On Monday, 18 November 2019 at 08:57:58 UTC, Russel Winder wrote: > Is SDL the right format? Cargo uses TOML to great effect. > > And TOML has, I suspect greater traction more widely than > SDL. I personally prefer SDL when it comes to nested data, but yeah, that would work as well. The point I was making is to just have 1 format. With dud that should be possible. For me the argument is that SDL and TOML are intended for human's to write configuration scripts, whilst XML and JSON are intended for computers to send data to other computers. A win-win move would be to have dud emit the other formats automatically as part of the compilation procedure, so to have always all of them present and synced on the content. It shouldn't be too much difficult, and maybe it's a cleaver way to move on from discussions about different formats.
Re: Blog series to teach and show off D's metaprogramming by creating a JSON serialiser
On Thursday, 31 October 2019 at 09:07:18 UTC, GreatSam4sure wrote: On Thursday, 31 October 2019 at 09:02:07 UTC, Paolo Invernizzi wrote: On Thursday, 31 October 2019 at 00:05:06 UTC, SealabJaster wrote: https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser1 Currently only the first post is out, as I'd like to collect feedback before writing any more. [...] Great Job, keep pushing! If you don't know it, I suggest to have a look to the venerable Philippe Sigaud "D Template Tutorial" for inspiration [1]. It was by far the most complete and comprensive tutorial covering every aspect of the D Template programming. It would be great to have also an updated version of it ... [1] https://github.com/PhilippeSigaud/D-templates-tutorial The tutorial you referred to is very comprehensive but i am confess is hard to understand. I have read it twice but i did not understand. It might be my fault but i will prefer a simple start with the newbie in mind I agree with you, a simple start is valuable, so I think it's good to have someone who is covering that, so thanks! On the other side, I'm missing an updated version of a "advanced" tutorial, mainly because, as you have noticed, advanced template programming is not so easy to learn! Thanks for your job!
Re: Blog series to teach and show off D's metaprogramming by creating a JSON serialiser
On Thursday, 31 October 2019 at 00:05:06 UTC, SealabJaster wrote: https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser1 Currently only the first post is out, as I'd like to collect feedback before writing any more. [...] Great Job, keep pushing! If you don't know it, I suggest to have a look to the venerable Philippe Sigaud "D Template Tutorial" for inspiration [1]. It was by far the most complete and comprensive tutorial covering every aspect of the D Template programming. It would be great to have also an updated version of it ... [1] https://github.com/PhilippeSigaud/D-templates-tutorial
Re: Blog Post: Beating std::visit Without Really Trying
On Wednesday, 16 October 2019 at 15:01:17 UTC, Atila Neves wrote: Please take a look at the cited pull request: it's a *trivial* Phobos patch, that can be added aside to the current implementation, blocked for months waiting for a _political_ decision. I don't think it's political: the change implies breakage for downstream users who inherit from the class who might not even care about @nogc. The proposed solution is to "add" a new @nogc method, with the correct signature, so that if someone want to write application and care about @nogc and @safe can rely on the D standard library being complaint to that. What's the problem with that, if not a _political_ one? We have a "wrong" signature, we don't break anything, but we add "correct" signature. That's what already was done in Mutex with lock_nothrow, but it's seen as "annoying to have to define/use alternate names for all the methods, though" This a technical point. The easiest way out in my opinion is to to inherit from it yourself and mark `receive` @nogc, as was suggested in the PR. That's can't be done without a cast, so we need to rely on trusted, and we go again to the starting point, as stated the pull request. It's simply embarrassing to explain to an external reviewer that a standard library method signature is inaccurate after 88 releases of version 2 of the language. And that yes, 'assumeNoGC' is needed, 'trust' that, and yes, an issue was filed along with a potential fix. Indeed. We're hardly alone in this: std::auto_ptr was/is an embarassment in C++. Then there's std::vector... And that's why I'm throwing a stone in the water: what's the 'concrete' procedures that the gatekeepers have in mind to improve Phobos quality for cases like that? Atila, that's really a _little_ change, if that can't be handled easily, what about handling _big_ changes?
Re: Blog Post: Beating std::visit Without Really Trying
On Wednesday, 16 October 2019 at 10:56:40 UTC, Atila Neves wrote: On Saturday, 12 October 2019 at 03:10:29 UTC, Walter Bright wrote: On 10/7/2019 12:37 AM, Paolo Invernizzi wrote: - adding another method to a class, marked @nogc, and (maybe) deprecating the previous method is seen as 'annoying', also if it's a _clear_ improvement over the actual situation (you can write _better_ code with that in place compared to the actual situation, I mean) @nogc doesn't actually enable writing better code. It doesn't change the generated code at all. I'm on the same boat with you, regarding what you wrote, but ... I still don't understand the number printed on the bar level. Atila is in charge of this, and he is because he's shown excellent judgement about these matters over the years. I think that I need to ruminate on Phobos v2. In the meanwhile, a much easier and shorter route to improving the D library ecosystem is to put something up on code.dlang.org, which requires no gatekeeping. While I agree on the ecosystem, the problem of keeping the actual Phobos modules in a good shape still apply. Please take a look at the cited pull request: it's a *trivial* Phobos patch, that can be added aside to the current implementation, blocked for months waiting for a _political_ decision. I understand that "there's always something else better for the language to do", but Phobos is the current "home sweet home" for everyone approaching D, and it's the first library inspected in details. It's simply embarrassing to explain to an external reviewer that a standard library method signature is inaccurate after 88 releases of version 2 of the language. And that yes, 'assumeNoGC' is needed, 'trust' that, and yes, an issue was filed along with a potential fix. I've full faith in your and Walter judgement, of course.
Re: Blog Post: Beating std::visit Without Really Trying
On Saturday, 12 October 2019 at 03:10:29 UTC, Walter Bright wrote: On 10/7/2019 12:37 AM, Paolo Invernizzi wrote: - adding another method to a class, marked @nogc, and (maybe) deprecating the previous method is seen as 'annoying', also if it's a _clear_ improvement over the actual situation (you can write _better_ code with that in place compared to the actual situation, I mean) @nogc doesn't actually enable writing better code. It doesn't change the generated code at all. I meant, writing better _source_ code, especially for reviewers. I'm on the same boat with you, regarding what you wrote, but ... I still don't understand the number printed on the bar level. Atila is in charge of this, and he is because he's shown excellent judgement about these matters over the years. I'm faithful for Atila judgement, and at the same time I've always liked also your pragmatism. Anyway, I'll sit waiting for a policy decision on cases similar to the one mentioned.
Re: Blog Post: Beating std::visit Without Really Trying
On Sunday, 6 October 2019 at 19:58:04 UTC, Walter Bright wrote: On 10/6/2019 2:59 AM, Paolo Invernizzi wrote: Well, so there's hope that _very little_ improvements will be merged, in a way or another? I mean, there's some sort of policy for things like that: https://github.com/dlang/phobos/pull/6730 Frankly speaking, the actual situation it's a little discouraging... We want a much higher bar for merging things than historically. A smaller, higher quality library is preferable to a kitchen sink library. The pull request I've shown is pretty simple: - std.socket is ... well... not the best piece of code out there - the `receive` method is usually in the _hot_ code path - it's not marked @nogc, and actually it does not allocate So: - adding @nogc will break derived classes that redefines the method (I still regret that the language was not shifted towards "final by default", years ago, as clearly that would be a *great* mitigation over that kind of problems) - adding another method to a class, marked @nogc, and (maybe) deprecating the previous method is seen as 'annoying', also if it's a _clear_ improvement over the actual situation (you can write _better_ code with that in place compared to the actual situation, I mean) I'm on the same boat with you, regarding what you wrote, but ... I still don't understand the number printed on the bar level. There's a number of recurring patterns of simple things to fix like the one above, with the same kind of problem to address. I humbly suggest the core team to just forge a general recipe for some of them, and stick with it, so that the number of the bar is less blurred. That scales, and encourage contribution. So, what do you think about starting a first one bases on cases similar to the above?
Re: Blog Post: Beating std::visit Without Really Trying
On Sunday, 6 October 2019 at 02:33:15 UTC, Walter Bright wrote: On 10/5/2019 6:58 AM, Seb wrote: Phobos is essentially dead/frozen (feature-wise). I beg to disagree. A couple cases in point: https://github.com/dlang/phobos/pull/7211 which is a re-imagining, rethinking of hexString. and: https://github.com/dlang/phobos/pull/7130 https://github.com/dlang/phobos/pull/7144 both of which work to remove autodecode from Phobos. 7130 in particular can use some help with anyone who wants to help drive this forward. Well, so there's hope that _very little_ improvements will be merged, in a way or another? I mean, there's some sort of policy for things like that: https://github.com/dlang/phobos/pull/6730 Frankly speaking, the actual situation it's a little discouraging...
Re: Beta 2.088.0
On Friday, 16 August 2019 at 11:47:23 UTC, Suliman wrote: On Friday, 16 August 2019 at 11:04:07 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.088.0 release, ♥ to the 58 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.088.0.html As usual please report any bugs at https://issues.dlang.org -Martin New releases become more and more strange. 30% of deprecation 30% removing futures Finally evolution, that's means that weak features need to die, to open living space for better features. There's no evolution, without removing features and (breaking) changes. /Paolo
Re: neomimalloc [D wrapper for mimalloc] - v0.0.3
On Friday, 5 July 2019 at 12:42:22 UTC, Andrea Fontana wrote: On Friday, 5 July 2019 at 09:57:58 UTC, Ernesto Castellotti wrote: I am happy to announce the first preliminary version of neomimalloc! And I'm happy Dlang is spreading in Italy too! Yay! Paolo
Re: Revisions to the DIP Process
On Friday, 7 June 2019 at 12:12:25 UTC, Mike Parker wrote: On Friday, 7 June 2019 at 11:19:07 UTC, Paolo Invernizzi wrote: On Friday, 7 June 2019 at 11:02:29 UTC, mate wrote: On Friday, 7 June 2019 at 10:57:42 UTC, Mike Parker wrote: No, the text is correct as published. See Andrei's announcement at the beginning of the AGM: https://youtu.be/cpTAtiboIDs?t=3041 I've seen the AGM, but doesn't that worth a post somewhere? /P Yes. I'll be writing up an overview of DConf once I've finished uploading the videos. That seems great! Thanks, Mike! /P
Re: Revisions to the DIP Process
On Friday, 7 June 2019 at 11:02:29 UTC, mate wrote: On Friday, 7 June 2019 at 10:57:42 UTC, Mike Parker wrote: No, the text is correct as published. See Andrei's announcement at the beginning of the AGM: https://youtu.be/cpTAtiboIDs?t=3041 I've seen the AGM, but doesn't that worth a post somewhere? /P
Re: nogc v0.5.0 - DIP1008 works!
On Monday, 27 May 2019 at 10:01:15 UTC, Atila Neves wrote: On Monday, 27 May 2019 at 09:07:48 UTC, Paolo Invernizzi wrote: On Monday, 27 May 2019 at 08:54:45 UTC, Atila Neves wrote: On Friday, 24 May 2019 at 16:51:11 UTC, ag0aep6g wrote: Then there's the fact that if a 3rd party library really does want to corrupt memory they can just tag all their functions with @trusted, and unless someone looks at their code nobody will be the wiser. ... and a @safe conscious programmer will not touch that library ever with a 5 five meters pole. I'm still not convinced that trusted code should accept generic system code ... can you elaborate more? I'm not convinced either - I'm having a dialogue to figure out potential issues. :-) My nice-try to reduce the problem is: trusted code block needs to by "manually verified" for safety by humans, so it should be "@safe pure", aka, if you can't perform the analysis looking only at the statements in the trusted block, that can't be marked trusted.
Re: nogc v0.5.0 - DIP1008 works!
On Monday, 27 May 2019 at 08:54:45 UTC, Atila Neves wrote: On Friday, 24 May 2019 at 16:51:11 UTC, ag0aep6g wrote: Then there's the fact that if a 3rd party library really does want to corrupt memory they can just tag all their functions with @trusted, and unless someone looks at their code nobody will be the wiser. ... and a @safe conscious programmer will not touch that library ever with a 5 five meters pole. I'm still not convinced that trusted code should accept generic system code ... can you elaborate more? Thanks, Paolo
Re: New and Unofficial OpenCV binding for D programming language
On Friday, 5 April 2019 at 13:19:22 UTC, Ferhat Kurtulmuş wrote:
On Friday, 5 April 2019 at 07:56:42 UTC, Paolo Invernizzi wrote:
On Thursday, 4 April 2019 at 23:08:21 UTC, Ferhat Kurtulmuş
wrote:
Hi folks!
D is awesome, but it is a shame that there is no any opencv
bindings for d yet. Actually we have it now :) Although I am
a new dlang learner, I dared to do it:
https://github.com/aferust/opencvd. C interface was taken
from gocv, and the implementation has been highly influenced
by gocv (maybe it is better to make git submodule it, since
gocv project is being updated very often?). I admit that it
is far from being a complete binding, but it is a beginning.
I invite you lovely and pro dlang community to grow it. I did
not want to add it to code.dlang.org before it become a
better binding.
Nice!
Version 3.x has an internal pointer in the mat struct, is that
changed with 4.x?
- Paolo
It still has it, if you what you mean:
Mat Mat_FromArrayPtr(int rows, int cols, int type, void* data){
return new cv::Mat(rows, cols, type, data);
}
No, I mean that the Mat structure has a MatSize MatStep member
with pointers to the struct data itself.
Until we have copy ctors, D can't have structures with internal
pointers, as they can be moved... that's something similar in C++
string, if I remember well, and that was the blocker that leaded
to the copy ctors DIP...
- P
Re: New and Unofficial OpenCV binding for D programming language
On Thursday, 4 April 2019 at 23:08:21 UTC, Ferhat Kurtulmuş wrote: Hi folks! D is awesome, but it is a shame that there is no any opencv bindings for d yet. Actually we have it now :) Although I am a new dlang learner, I dared to do it: https://github.com/aferust/opencvd. C interface was taken from gocv, and the implementation has been highly influenced by gocv (maybe it is better to make git submodule it, since gocv project is being updated very often?). I admit that it is far from being a complete binding, but it is a beginning. I invite you lovely and pro dlang community to grow it. I did not want to add it to code.dlang.org before it become a better binding. Nice! Version 3.x has an internal pointer in the mat struct, is that changed with 4.x? - Paolo
Re: DIP 1018--The Copy Constructor--Formal Review
On Monday, 25 February 2019 at 20:23:58 UTC, Andrei Alexandrescu wrote: On 2/25/19 3:23 PM, Jacob Carlborg wrote: On 2019-02-25 20:24, Mike Parker wrote: From the process document: “the DIP Manager or the Language Maintainers may allow for exceptions which waive requirements or responsibilities at their discretion.” Having it documented doesn't make it less flawed. Jacob, are there amends you need to make to the DIP? Honestly, I've not understood the rationale or the covered use case in letting the copy ctor mutate the ref source parameters... Sincerely, without polemical intent. - P
Re: DIP 1017--Add Bottom Type--Formal Assessment
On Wednesday, 30 January 2019 at 20:50:42 UTC, Johannes Loher wrote: Am 30.01.19 um 15:05 schrieb Mike Parker: Given the nature of the feedback in both review rounds this DIP has gone through, Walter has decided to reject his own DIP. He still believes there is a benefit to adding a bottom type to the language, but this proposal is not the way to go about it. He hopes to revisit the issue in the future. Thanks to everyone who provided feedback. I believe this is a good decision and the proper way forward. I also think that there is indeed a benefit in adding a bootom type to the language so I'd be happy to help with a new attempt as much my limited knowledge of type theory permits. +1 Well done Walter, for the professionalism in handling the decision, and for the bravery in trying to push something he believe useful for the language, also if he is not as competent as Timon in this field. Kudos to you, for the example given, and for the temperance! -- P
Re: My Meeting C++ Keynote video is now available
On Wednesday, 16 January 2019 at 16:30:17 UTC, Steven Schveighoffer wrote: On 1/16/19 10:06 AM, Paolo Invernizzi wrote: I'm waiting, for example, for a revamp of IO, just to start... We're working on it... https://github.com/schveiguy/iopipe https://github.com/MartinNowak/io -Steve I was exactly referring to that two... they are great, and I've used both! Despite that, they seem stalled: any plan to go ahead in the medium term? Thanks for your work (and to Martin too) --- Paolo
Re: My Meeting C++ Keynote video is now available
On Wednesday, 16 January 2019 at 14:59:20 UTC, Steven Schveighoffer wrote: On 1/15/19 4:37 AM, Martin Tschierschke wrote: [...] I should have said that your point is mostly correct, just that this is a bad example :) I've looked for ORM on code.dlang.org, and never found one yet that I liked. So the answer would take infinite seconds to complete. But let's say we put ORM into Phobos. Certainly, it would get heavy use, but I would be likely to believe that it would not cover the problem space completely, and leave quite a bit to be desired. I think that there are some things that can go into the standard library and live there happily. There are other things that should be left to the community, even though they are essential, simply because locking into one implementation/API/idea is too restrictive. -Steve +1 I'm waiting, for example, for a revamp of IO, just to start... --- Paolo
Re: DLS (D Language Server) v0.20
On Friday, 28 December 2018 at 18:50:39 UTC, David Gileadi wrote: On 12/28/18 4:14 AM, Laurent Tréguier wrote: Hello, and merry Christmas! (a bit late, but whatever) This is an excellent update--the update Just Works™ with VSCode on my mac, and functions very nicely too. Thanks! I might suggest that you perhaps rename the VSCode extension to remove "VSCode" from the name (as it's redundant) and add "D Language" (because the current name makes it a bit hard to discover). +1, It's a great piece of software, so thank you. I'm using it on Mac also, when I'm not using vim: works like a charm! --- Paolo
Re: Blog post: What D got wrong
On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe wrote: 2) LETTING US TURN THEM OFF. SERIOUSLY WHY DON'T WE HAVE `virtual`, `throws`, `impure` AND THE REST?! THIS IS SO OBVIOUS AND THE LACK OF THEM IS UNBELIEVABLY FRUSTRATING. Well, we had virtual, it was reverted I know, I'm repeating this kind of things in a trollish way since 2004, but... *sigh* /Paolo
Re: A brief survey of build tools, focused on D
On Monday, 10 December 2018 at 21:01:08 UTC, H. S. Teoh wrote: And almost no build system handles reliable builds correctly when the build description is changed -- Button does, but it's in the extreme minority, and is still a pretty young project that's not widely known). Tup [1] does, and it's pretty reliable on that: I think Botton was inspired by it. Anyway, you are totally right: +1 on all your points! [1] http://gittup.org/tup/ -- Paolo
Re: D compilation is too slow and I am forking the compiler
On Thursday, 22 November 2018 at 13:19:58 UTC, Andrej Mitrovic wrote: On Thursday, 22 November 2018 at 11:16:26 UTC, Paolo Invernizzi wrote: BTW, it's nice to see again the Secret Squirrel on the forum, in these days: welcome back Andrej! /Paolo Oh hey there too! I'm sorry if I can't recall you, though. ¯\_(ツ)_/¯ Oh, no problem... eheh I mostly lurk around here these days. Yep, the same... But I still use D heavily, at work. Well, the same here; not so heavily right now, my CTO is not sure anymore about the "case for D", but well, we have just delivered a D (medical) codebase to one of our customer... Let's see... /Paolo
Re: D compilation is too slow and I am forking the compiler
On Thursday, 22 November 2018 at 10:51:45 UTC, Andrej Mitrovic wrote: BTW, it's nice to see again the Secret Squirrel on the forum, in these days: welcome back Andrej! /Paolo
Re: New Initiative for Donations
On Sunday, 28 October 2018 at 13:06:53 UTC, Laeeth Isharc wrote: Banks are special because of the payments system and because of lending. In October 2008 Gordon Brown was within two hours of shutting down the banking system and declaring a state of emergency. If that had happened nobody would have been able to make payments and new lending would have come to a halt. In 2038 you won't need banks to make payments because cryptocurrencies will be a viable alternative. And lending is already being provided by asset managers. So the justification for the combination of leverage and the mismatch in liquidity and risk of banks deposit liabilities and their assets will disappear. Only one word: Huerta de Soto. - Paolo
Re: Webassembly TodoMVC
On Sunday, 23 September 2018 at 17:53:32 UTC, Suliman wrote: What do you think of the struct approach compared to a traditional jsx/virtual-dom? jsx is sucks. Look at Vue.js way, if you will able to fo you framework Vue-style it will be perfect! Being a Vue user for three years now, I completely agree. /P
Re: fearless v0.0.1 - shared made easy (and @safe)
On Tuesday, 18 September 2018 at 17:20:26 UTC, Atila Neves wrote: The `shared` keyword currently means one of two things: 1. You can use core.atomic with it 2. It's some struct and you BYOM (Bring Your Own Mutex) [...] Whahh!! You made my day! /Paolo
Re: GitHub could be acquired by Microsoft
On Monday, 4 June 2018 at 07:53:13 UTC, drug wrote: 04.06.2018 09:02, Anton Fediushin пишет: On Monday, 4 June 2018 at 04:40:44 UTC, Jonathan M Davis wrote: On the bright side, maybe this will encourage online repo hosting to become less of a monopoly as folks move elsewhere due to their concerns about Microsoft. - Jonathan M Davis Can't agree more: GitLab and Bitbucket deserve more attention. Speaking of which, there's huge spike [1] in project imports on GitLab. These are some great news for it, I hope it doesn't crash. [1] https://monitor.gitlab.net/dashboard/db/github-importer?orgId=1 Gitlab has a big (for me) advantage being self hosted standalone system I can use privately. Its free version has restrictions comparing to enterprise version but very usable. What about sexy modern design it's annoying (for me again) that this design changes frequently, it forces me almost every update to find where menus and buttons I used before placed now. No more restrictions for using GitLab for open source projects [1], both SaaS and Self-Hosted. It's really a big opportunity... [1] https://about.gitlab.com/2018/06/05/gitlab-ultimate-and-gold-free-for-education-and-open-source/ /Paolo
Re: Reserved 1.0.0
On Sunday, 20 May 2018 at 09:15:12 UTC, Andrea Fontana wrote: On Sunday, 20 May 2018 at 07:33:39 UTC, Fra Mecca wrote: On Wednesday, 16 May 2018 at 08:38:05 UTC, Andrea Fontana wrote: I released another small library on behalf of the company I work for (http://lab.2night.it). It is called "reserved", and it's a small library you can use to run your D webpages/service. It is focused on simplicity (no dependencies) and fast setup. It use scgi to interface itself with nginx/apache/etc through unix sockets. More info: http://code.dlang.org/packages/reserved Comments are welcome. Andrea Fontana Ciao Andrea, it is very nice to see an italian company (being an italian myself) publishing in the forum and using D. Thanks for the contribution. Francesco We should try to spread the word :) Andrea Concordo :-) /Paolo
Re: The D Language Foundation at Open Collective
On Monday, 19 March 2018 at 09:42:11 UTC, rumbu wrote: On Monday, 19 March 2018 at 07:22:42 UTC, Paolo Invernizzi wrote: On Thursday, 15 March 2018 at 12:36:24 UTC, Meta wrote: On Wednesday, 14 March 2018 at 12:00:42 UTC, Seb wrote: Yeah, the idea is that 5$ a month isn't much (~ one coffee in most countries), but if 500 people donate one coffee a month, you get the entire coffee machine with a warp engine :) Sorry to derail, but I had to ask: where does 1 coffee (even extra large) cost $5 USD? Let me know so I know to never move there. Yeah... I still prefer an 'espresso', that in Italy is simply called 'caffè': 1.00 euro in Milano. An original Cappuccino, italiano, is 1.20 euro... /Paolo I wonder how did you survive in Italy without Starbucks? :) Well, things are moving... [1] I'm wondering if they will do the 'espresso solo' the Italian Way guess not! Anyhow, I've drank a very very good "caffè espresso" in Silicon Valley, in a Google Plex building... There was a guy with a real passion about it, and he was able to use an Italian Coffè Machine in the right way. :-) [1] https://starbucksreservecareers.it/index.html
Re: The D Language Foundation at Open Collective
On Thursday, 15 March 2018 at 12:36:24 UTC, Meta wrote: On Wednesday, 14 March 2018 at 12:00:42 UTC, Seb wrote: Yeah, the idea is that 5$ a month isn't much (~ one coffee in most countries), but if 500 people donate one coffee a month, you get the entire coffee machine with a warp engine :) Sorry to derail, but I had to ask: where does 1 coffee (even extra large) cost $5 USD? Let me know so I know to never move there. Yeah... I still prefer an 'espresso', that in Italy is simply called 'caffè': 1.00 euro in Milano. An original Cappuccino, italiano, is 1.20 euro... /Paolo
Re: Release D 2.079.0
On Wednesday, 7 March 2018 at 14:53:09 UTC, Sönke Ludwig wrote: But why wouldn't it be possible to make a quick bugfix release with the current scheme? It has happened in the past. Granted, if a 0.8.5-beta.1 is already tagged, then using 0.8.5 for a quick intermediate release would be bad, but at that point the beta could likely also be turned into a full release pretty quickly. Well, I don't know why, but quick is more than 30 days right now using the current release procedure... https://github.com/vibe-d/vibe.d/issues/2058 https://github.com/vibe-d/vibe.d/releases Anyway, never mind! /Paolo
Re: Release D 2.079.0
On Wednesday, 7 March 2018 at 10:13:29 UTC, Sönke Ludwig wrote: Well, for all of the recent releases we made sure that there was no breakage for new compiler versions. This release was an exception, because I didn't manage to put out the fixed release in time. The plan is to have all future releases go back to the normal mode where the new compiler version always works. Since std.experimental isn't involved from now on, it shouldn't even be necessary anymore to put out new vibe.d releases for new DMD versions, because DMD/Phobos already checks for regressions against vibe.d and all breaking changes should simply result in a deprecation warning. That's fine, thanks. As for the versioning scheme, currently almost all new releases have some small breaking change or deprecation. If I'd use the "minor" version for that, then there would be no way to signal that a release makes broad and more disruptive changes, such as the 0.8.0 release. But all of this will change, as the remaining parts get pushed to separate repositories one-by-one, with their own version starting at 1.0.0. I understand your reasoning, but there's value in being able to just rapidly fix something with a new release, or just port some master bug-fixes into a released version branch. DMD is experiencing a very enjoyable release process of patch versions, thanks to Martin and the team. It your concern is only related to the best way to inform the users about a broad and disruptive change in vibe-d, I suggest to simply use the usual channels for that, change logs and announce forum. My impression is that there's a lot of value in using patch for patch, instead of using patch for development, also in a zero major, so I maybe you should consider that change, or at least, investigate a little about that opportunity. /Paolo
Re: Release D 2.079.0
On Wednesday, 7 March 2018 at 04:02:18 UTC, Seb wrote: On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer wrote: On 3/6/18 2:30 PM, Martin Nowak wrote: On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote: But if needed, you could have your dub package depend on a prior version. http://code.dlang.org/packages/stdx-allocator ;) This is the answer, vibe.d should depend on stdx-allocator. -Steve Vibe.d (and a lot of other projects) do depend on this package, see e.g. https://github.com/vibe-d/vibe.d/pull/1983 Also many packages already depend on vibe.d-0.8.3, but it's in rc1 atm and not released as the latest stable tag yet, which is the reason for Atila's justified complaint. The point is just to persuade Sonke to do his development in the minor version and increase it during every vibe-d release, and keep the patch version for fast fixes of the latest released vibe-d when a new version of the compiler is being released. The actual policy is just an ask for problems... It's not a big deal to fix the breakage on the latest released vibe-d code, it's a fast process. But it's a problem in just coordinating the next release of vibe-d with the release of the compiler, if you need to do this, like in this case. /Paolo
Re: State of D 2018 Survey
On Wednesday, 28 February 2018 at 13:41:56 UTC, Mike Parker wrote: About a month ago, Sebastian Wilzbach sent an email out to a few of the core D folks asking for feedback on a survey he had put together. He thought it would be useful for the Foundation to use in order to make decisions about where to expend development efforts. Eventually Andrei gave his stamp of approval, the survey questions were tweaked, and then it was ready to roll. Of course I would love for you to read my blog post announcing it, but if you want to skip the prose and go straight to the good stuff, here's the survey link: https://seb134.typeform.com/to/H1GTak The blog: https://dlang.org/blog/2018/02/28/the-state-of-d-2018-survey/ Reddit: https://www.reddit.com/r/d_language/comments/80w29n/the_state_of_d_2018_survey/ Done! Great initiative! I'm glad to see how things are moving in DLang recently! :-P
Re: Beta 2.079.0
On Friday, 23 February 2018 at 11:57:05 UTC, Martin Nowak wrote: On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote: Given the effort required for a language change, it's seductive to streamline seemingly small changes, but it certainly increases the risk of design mistakes, thanks for appealing against this one. -Martin Thanks to you, sincerely, It was a nice try to solve a problem, and trying to solve problems is the 'right thing to do'. I'm really pleased to see the D community developing the antibodies needed to support a strong and sane grown of D! /Paolo
Re: Beta 2.079.0
On Wednesday, 21 February 2018 at 10:47:45 UTC, Eugene Wissner wrote: On Wednesday, 21 February 2018 at 10:24:41 UTC, Paolo Invernizzi wrote: On Wednesday, 21 February 2018 at 10:15:48 UTC, Jonathan M Davis wrote: On Wednesday, February 21, 2018 10:04:01 Kagamin via Digitalmars-d-announce wrote: On Tuesday, 20 February 2018 at 22:54:43 UTC, H. S. Teoh wrote: > Yeah, personally I'd avoid writing it that way too. There's no other way to use this feature though. Some of us think that it's a bad feature and have no intention of ever using it, though once it's in the language, we all have to worry about dealing with code that does use it. - Jonathan M Davis Was there a DIP for that? /Paolo https://issues.dlang.org/show_bug.cgi?id=13855 https://github.com/dlang/dmd/pull/6589 And here we are again.
Re: Beta 2.079.0
On Wednesday, 21 February 2018 at 10:15:48 UTC, Jonathan M Davis wrote: On Wednesday, February 21, 2018 10:04:01 Kagamin via Digitalmars-d-announce wrote: On Tuesday, 20 February 2018 at 22:54:43 UTC, H. S. Teoh wrote: > Yeah, personally I'd avoid writing it that way too. There's no other way to use this feature though. Some of us think that it's a bad feature and have no intention of ever using it, though once it's in the language, we all have to worry about dealing with code that does use it. - Jonathan M Davis Was there a DIP for that? /Paolo
Re: Beta 2.077.1
On Thursday, 30 November 2017 at 13:57:37 UTC, Martin Nowak wrote: On 11/26/2017 02:27 PM, Paolo Invernizzi wrote: 18012 is an ice regression towards 2.076.1 ... Fixed with 2.077.1, was a duplicate of https://issues.dlang.org/show_bug.cgi?id=17955. Thanks Martin!
Re: Beta 2.077.1
On Thursday, 23 November 2017 at 11:43:08 UTC, Martin Nowak wrote: First beta for the 2.077.1 point release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.077.1.html Please report any bugs at https://issues.dlang.org - -Martin 18012 is an ice regression towards 2.076.1 ... /P
Re: dpeq - native PSQL extended query protocol client
On Monday, 4 September 2017 at 12:07:29 UTC, Jacob Carlborg wrote: Ah, ok. I didn't know about hb-ddb until you started this thread. I'm currently one of the maintainers of ddb and I haven't seen anything upstreamed there. Me too... /P
Re: Visual Studio Code code-d serve-d beta release
On Thursday, 24 August 2017 at 21:45:48 UTC, WebFreak001 wrote: On Thursday, 24 August 2017 at 08:21:41 UTC, Paolo Invernizzi wrote: On Wednesday, 23 August 2017 at 20:10:01 UTC, WebFreak001 wrote: [...] Can you check? If I want to build it, what repo and revision should I use? [...] git clone https://github.com/Pure-D/serve-d.git cd serve-d dub build --build=release That's what I've done above in the previous post... I was meaning, in `.vscode/extensions/webfreak.code-d-beta-0.17.3/bin` in the macOS installation there's a linux workspace-d binary. If I want to rebuild it for macOS, what version of `workspace-d` have I to use? There's no `workspace-d` source files in `webfreak.code-d-beta-0.17.3`, only the binary. Thanks! --- Paolo
Re: Visual Studio Code code-d serve-d beta release
On Wednesday, 23 August 2017 at 20:10:01 UTC, WebFreak001 wrote: On Wednesday, 23 August 2017 at 15:41:02 UTC, Paolo Invernizzi wrote: On Saturday, 5 August 2017 at 22:43:31 UTC, WebFreak001 wrote: [...] It seems that under macOS, the linux executable is used, with a fresh install... iMac:~ pinver$ uname -a Darwin iMac.local 17.0.0 Darwin Kernel Version 17.0.0: Wed Aug 16 20:06:51 PDT 2017; root:xnu-4570.1.45~23/RELEASE_X86_64 x86_64 iMac:~ pinver$ file /Users/pinver/.vscode/extensions/webfreak.code-d-beta-0.17.3/bin/serve-d/serve-d /Users/pinver/.vscode/extensions/webfreak.code-d-beta-0.17.3/bin/serve-d/serve-d: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=788ec4845beac53f20ad0c0279f6b143bf9e42cc, with debug_info, not stripped Version 0.17.3 ... --- Paolo uh serve-d doesn't have any prebuilt binaries yet so that is compiled on your PC and should be correct Well, it would be really strange that dmd was able to compile and link a linux executable on my iMac, no? :-O Anyway... iMac:serve-d pinver$ pwd /Users/pinver/.vscode/extensions/webfreak.code-d-beta-0.17.3/bin/serve-d iMac:serve-d pinver$ dub build --build=release Package xdgpaths can be upgraded from 0.2.3 to 0.2.4. Package dub can be upgraded from 1.2.1 to 1.2.2. Package libdparse can be upgraded from 0.7.0 to 0.7.1. Use "dub upgrade" to perform those changes. Performing "release" build using dmd for x86_64. eventsystem 1.1.0: building configuration "library"... dunit 1.0.14: building configuration "library"... painlesstraits 0.2.0: building configuration "library"... painlessjson 1.3.8: building configuration "library"... dub 1.2.1: building configuration "library"... libdparse 0.7.0: building configuration "library"... ../../../../../.dub/packages/libdparse-0.7.0/libdparse/src/dparse/ast.d(1346,10): Deprecation: cannot implicitly override base class method object.Object.opEquals with dparse.ast.Declaration.opEquals; add override attribute isfreedesktop 0.1.1: building configuration "library"... xdgpaths 0.2.3: building configuration "library"... standardpaths 0.7.1: building configuration "default"... workspace-d 2.10.1: building configuration "library"... ../../../../../.dub/packages/libdparse-0.7.0/libdparse/src/dparse/ast.d(1346,10): Deprecation: cannot implicitly override base class method object.Object.opEquals with dparse.ast.Declaration.opEquals; add override attribute serve-d ~master: building configuration "application"... ../../../../../.dub/packages/libdparse-0.7.0/libdparse/src/dparse/ast.d(1346,10): Deprecation: cannot implicitly override base class method object.Object.opEquals with dparse.ast.Declaration.opEquals; add override attribute Linking... iMac:serve-d pinver$ file serve-d serve-d: Mach-O 64-bit executable x86_64 Now... iMac:bin pinver$ file /Users/pinver/.vscode/extensions/webfreak.code-d-beta-0.17.3/bin/workspace-d /Users/pinver/.vscode/extensions/webfreak.code-d-beta-0.17.3/bin/workspace-d: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=5cb6f08ed280d886418aeeeb4332a380d9cc44aa, not stripped Again linux, there's no source code in the extension, so, I think that this binary was installed directly along with the plugin... Can you check? If I want to build it, what repo and revision should I use? --- /Paolo
Re: Visual Studio Code code-d serve-d beta release
On Saturday, 5 August 2017 at 22:43:31 UTC, WebFreak001 wrote: You might remember the blog post from a while back about workspace-d and serve-d, I just released a beta version on the visual studio marketplace that allows you to try out the latest features of serve-d. Note that this version might easily break in the future, but for the next few days I am trying to gain some feedback. If you are a user of code-d and if you want to try out the new version please uninstall code-d and install code-d-beta (https://marketplace.visualstudio.com/items?itemName=webfreak.code-d-beta, it's version 0.16.1) and just try to use it. [...] It seems that under macOS, the linux executable is used, with a fresh install... iMac:~ pinver$ uname -a Darwin iMac.local 17.0.0 Darwin Kernel Version 17.0.0: Wed Aug 16 20:06:51 PDT 2017; root:xnu-4570.1.45~23/RELEASE_X86_64 x86_64 iMac:~ pinver$ file /Users/pinver/.vscode/extensions/webfreak.code-d-beta-0.17.3/bin/serve-d/serve-d /Users/pinver/.vscode/extensions/webfreak.code-d-beta-0.17.3/bin/serve-d/serve-d: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=788ec4845beac53f20ad0c0279f6b143bf9e42cc, with debug_info, not stripped Version 0.17.3 ... --- Paolo
Re: Beta 2.075.0-b2
On Wednesday, 5 July 2017 at 17:59:16 UTC, Martin Nowak wrote: Second beta for the 2.075.0 release. Comes with a couple of more fixes for dmd, phobos, and dub: https://github.com/dlang/dmd/compare/v2.075.0-b1...v2.075.0-b2 https://github.com/dlang/phobos/compare/v2.075.0-b1...v2.075.0-b2 https://github.com/dlang/dub/compare/v1.4.0-beta.1...v1.4.0-beta.2 Downloads and changelog here: http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.075.0.html Please report any bugs at https://issues.dlang.org. - -Martin Installed on macOS via brew... pinver$ /usr/local/Cellar/dmd/2.075.0-b2/bin/dmd --version DMD64 D Compiler v2.074.1 /Paolo
Re: Release candidates vibe.d 0.8.0-rc.2 and vibe-core 1.0.0-rc.2
On Wednesday, 28 June 2017 at 08:37:40 UTC, Andre Pany wrote: On Tuesday, 27 June 2017 at 09:20:40 UTC, Sönke Ludwig wrote: Am 22.06.2017 um 10:55 schrieb Sönke Ludwig: There have been some minor fixes and vibe.d 0.8.0-rc.2 and vibe-core 1.0.0-rc.2 have been tagged. The final release is rescheduled for Monday, July the 3rd. Still not able to use it for this [1] ... Works fine in Vibe 0.7.31 with libevent ... /Paolo [1] https://github.com/rejectedsoftware/vibe.d/issues/1757
Re: Trip notes from Israel
On Friday, 26 May 2017 at 11:32:21 UTC, Andrei Alexandrescu wrote: On 5/22/17 6:53 PM, cym13 wrote: One thing that several of those people emphasized is we need to improve leadership and decision. "You are trying to do democracy and democracy doesn't work here" (by a successful serial entrepreneur). Walter and I have implicitly fostered a kind of meritocracy whereby it's the point/argument that matters. It should be meritocracy of the person - good proven contributors have more weight and new people must prove themselves before aspiring to influence. Historically, anyone with any level of involvement with D could hop on the forum and engage the community and its leadership in debate. Subsequently, they'd be frustrated with the ensuing disagreement and also get a sense of cheapness - if I got to carry this unsatisfactory debate with the language creator himself, what kind of an operation is this? Since anything can be debated by anyone, everything gets debated by everyone. Anyone can question any decision at any time and expect a response. It's the moral equivalent of everyone in a 5000-person company building can expect to stop the CEO on the way to his/her office and engage them in a conversation of any length. The net consequence is slower progress. Where we need to be is fostering strong contributions and contributors. The strength of one's say is multiplied by his/her contributions (and that simply means pulled PRs, successful DIPs - not "won" debates). I strongly suggest to have a clear and transparent procedure to collect impressions and suggestion from *commercials* that are *actually using* the language in production, and separate those from other things to discuss. Guru meditation: try not to loose talented contributors involved... Dicebot, Kenji, Bearofile... what's happened, and what can be done on this front? Sincerely /Paolo
Re: DMD now has colorized syntax highlighting in error messages
On Monday, 15 May 2017 at 04:33:39 UTC, ketmar wrote:
On Monday, 15 May 2017 at 03:09:09 UTC, Walter Bright wrote:
On 5/14/2017 7:44 PM, ketmar wrote:
sorry for being rude,
Then please do not post rude comments. We expect professional
decorum here.
sorry. i never got any money for using D, so i'm certainly not
a professional ('cause professionals are the people which get
payment for their work). sorry again for polluting NG with my
unprofessional writings. i will stop doing that immediately
after this post.
Rude or not, I think ketmar is right...
/P
Re: Cap'n Proto for D v0.1.2
On Thursday, 20 April 2017 at 18:25:03 UTC, Jonathan M Davis wrote: On Tuesday, April 18, 2017 18:09:54 Thomas Brix Larsen via Digitalmars-d- announce wrote: LOL. Oh, I remember a coworker bringing up this library. It's the one that the site claimed was infinitely faster than protocol buffers (IIRC, because of some work that protocol buffers does that Captain Proto skips entirely). Exactly! Well, "Captain Proto" knows what he does, as he was the man that wrote google protobuf. The same way of working of Cap'n Proto is what Google introduced later in FlatBuffer... but it's missing totally all the good stuff taken from e-lang, that in my opinion is a big plus. Don't take me wrong, I know that a lot is to be implemented, today, but I love man with a clean path towards brilliant ideas [1] [1] https://capnproto.org/rpc.html /Paolo
Re: Cap'n Proto for D v0.1.2
On Tuesday, 18 April 2017 at 18:09:54 UTC, Thomas Brix Larsen wrote: "Cap’n Proto is an insanely fast data interchange format and capability-based RPC system. Think JSON, except binary. Or think Protocol Buffers, except faster." This is the initial public release of my optimized port of the Java implementation of Cap'n Proto. State: * Passes Cap'n Proto testsuite. * Optimized. Just a little slower than the official C++ implementation (see benchmarks on github). * Missing RPC part of Cap'n Proto. http://code.dlang.org/packages/capnproto-dlang https://github.com/ThomasBrixLarsen/capnproto-dlang Great Job! I'm following Cap'n Proto, and it's very very interesting... I would love also the RPC part, maybe based on Vibe... have you any plan to implement that? I'm really curious to try it! --- Paolo
Re: dmd Backend converted to Boost License
On Friday, 7 April 2017 at 15:14:40 UTC, 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! Congrats! That's a big win, and you deserve all the merits! Enjoy the moment! --- Paolo
Re: This Week in D: debugging uncaught exceptions
On Monday, 8 August 2016 at 04:24:45 UTC, Adam D. Ruppe wrote: I decided to write up a think on untrapping exceptions this week: http://arsdnet.net/this-week-in-d/2016-aug-07.html Next week I'll prolly talk about calling D from Ruby. Last week, we had a status report from Stefan Koch on his CTFE engine. If you aren't already following this, every Sunday night or Monday morning, the little newsletter comes out with a snapshot of forum activity and about half of them have some kind of longer article or tip or other such educational content. The RSS feed (linked on the page) is also a single-page archive so you can search for old things there too! Thank you Adam, this is pure gold stuff to know! /Paolo
Re: Release D 2.071.0
On Saturday, 9 April 2016 at 16:56:50 UTC, Vladimir Panteleev wrote: since I can run the Windows version via Wine. But if no one else needs this then it's fine. Me too /P
Re: IAP Tools for D
On Sunday, 20 December 2015 at 01:16:46 UTC, Jakob Jenkov wrote: [...] That depends on what API you use, and how much "meta data" (e.g. class names and property names) you write in the serialized ION data. ION is quite flexible about how much meta you want to include. [...] I suggest to compare also against this [1]. The author, Kenton Varda, was the primary author of Protocol Buffers version 2, which is the version that Google released open source. [1] https://capnproto.org /Paolo
Re: "Programming in D" paper book is available for purchase
On Wednesday, 19 August 2015 at 00:57:32 UTC, Ali Çehreli wrote: Enjoy, and go buy some books! ;) My printed copy is just arrived... very good job Ali! Paolo
Re: Moving forward with work on the D language and foundation
On Monday, 24 August 2015 at 18:43:01 UTC, Andrei Alexandrescu wrote: Hello everyone, Following an increasing desire to focus on working on the D language and foundation, I have recently made the difficult decision to part ways with Facebook, my employer of five years and nine months. I understand very well the difficulty of decisions of such kinds, that's why you have all my respect.
Re: Coedit 1 gold released
On Thursday, 11 June 2015 at 06:28:08 UTC, Jacob Carlborg wrote: On 2015-06-10 08:57, Andrei Alexandrescu wrote: I can haz OSX pliz pliz ok thx bye -- Andrei Having D/Objective-C merged [1] would make it a lot easier. [1] https://github.com/D-Programming-Language/dmd/pull/4321 +1000
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Monday, 30 March 2015 at 18:20:39 UTC, Walter Bright wrote: Well put. My brain still thinks in terms of loops. Sadly, mine also... ;-P
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Saturday, 28 March 2015 at 02:31:37 UTC, Laeeth Isharc wrote: The data points we have suggest that the scarcity of D programmers is an imaginary problem, because enterprises just hire good people and they pick it up (ask Don at Sociomantic or Dicebot for example). Modern business has a misplaced emphasis on credentials. And if you have a large code base it is not like a new guy can just dive in, anyway. There is a signalling effect at work also, at least for the time being. +1 /P
