Re: CTFE write message to console
On Thursday, 4 April 2024 at 15:43:55 UTC, Carl Sturtivant wrote:
On Thursday, 4 April 2024 at 15:07:21 UTC, Richard (Rikki)
Andrew Cattermole wrote:
Ah yes, I forgot about that particular thing, doesn't see much
use as far as I'm aware.
It should be working though.
```D
enum X = computeX("A message");
string computeX(string msg) {
auto s = "CTFE msg: ";
auto x = imported!"std.format".format("%s%s\n", s, msg);
__ctfeWrite(x);
return x;
}
void main() {
import std.stdio;
writeln(X);
}
```
Produces no output on compilation, and writes out `CTFE msg: A
message` when run.
pragma(msg, x) ?
Re: The std.file rename method fails in the docker environment.
On Wednesday, 13 March 2024 at 23:59:24 UTC, zoujiaqing wrote: On Wednesday, 13 March 2024 at 22:16:13 UTC, Sergey wrote: On Wednesday, 13 March 2024 at 21:49:55 UTC, zoujiaqing wrote: this is bug in D. It seems like a bug in Hunt-framework. And Hunt - is an abandoned project. Hunt Framework call std.file rename function. but this function can't move file from docker container to host machine. As Jonathan said, it's NOT possible to move aka rename files across different filesystems. You can NOT do that in D, in C, in Python, every language ... is a OS error. Try to copy the file, and then delete the original one. /P
Re: Would you recommend TDPL today?
On Tuesday, 16 January 2024 at 02:25:32 UTC, matheus wrote: Hi, I'm mostly a lurker in these Forums but sometimes I post here and there, my first language was C and I still use today together with my own library (A Helper) which is like a poor version of STB (https://github.com/nothings/stb). [...] I suggest also Ali book, Programming in D, is excellent [1] [1] http://ddili.org/ders/d.en/index.html
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: macOS Sonoma Linker Issue
On Wednesday, 4 October 2023 at 07:43:29 UTC, Tuna Celik wrote: On Tuesday, 3 October 2023 at 23:55:05 UTC, confuzzled wrote: [...] I'm also suffering from the same problem. It seems to be an Xcode 15 issues, everything works fine with 14
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
Ideas to reduce error message size?
Hello everybody,
If a compilation error is thrown with CTFE involved, the 'called
from here' is like:
```
src/api3.d(2010): Error: uncaught CTFE exception
`object.Exception("42703: column \"system_timestamp_ms\" does not
exist. SQL: select coalesce(count(system_timestamp_ms),0) from
dev_samples where device_id = $1")`
src/api3.d(39):thrown from here
src/api3.d(49):called from here:
`checkSql(Schema("public",
src/dget/db.d(276): Error: template instance
`api3.forgeSqlCheckerForSchema!(Schema("public", **BAZILLIONS of lines**> error instantiating
```
Simple question: there's a pattern to reduce the outputted stuff
someway? Everything is related to a single struct, `Schema`, used
during compile time stuff.
Thank you,
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: A Programmer's Dilema: juggling with C, BetterC, D, Macros and Cross Compiling, etc.
On Monday, 1 May 2023 at 16:57:39 UTC, Dadoum wrote: On Sunday, 30 April 2023 at 17:51:15 UTC, Eric P626 wrote: But how is this possible in a cross-compiling context. I am not sure if I can do that with the D language either as pure D or better C. DMD does not seem to offer cross compiling. GDC can compile better C, but not sure mingw can compile D/betterC code. I build programs for macOS, iOS, Windows with ldc2 cross-compiling capabilities from my Linux computer, and the experience is okay, the executables are working fine but the set-up is a bit complicated, you need to copy files from the windows toolchain, copy your ldc config and edit it with some stuff, and do that at each ldc2 update. If you just need cross-architecture, then gdc is a good option since it is compiled in a lot of cross compilation toolchains. However, I never managed to build a working gdc myself with ucrt or mingw cross-compilation capabilities, it always ends up with a compiler unable to link or executables that can't be executed on Windows. Indeed, at DeepGlance we are cross-compiling and cross linking with LDC and LLVM ld.lld, from macOS to linux. I'm interested in understanding if it's feasible to use importC with ffmpeg API and cross-compile and link them.
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: toString best practices
On Wednesday, 15 February 2023 at 12:15:18 UTC, Bastiaan Veelo
wrote:
On Thursday, 9 February 2023 at 17:49:58 UTC, Paolo Invernizzi
wrote:
```
import std.format, std.range.primitives;
struct Point(T)
{
T x, y;
void toString(W)(ref W writer, scope const ref
FormatSpec!char f) const
if (isOutputRange!(W, char))
{
put(writer, "(");
formatValue(writer, x, f);
put(writer, ", ");
formatValue(writer, y, f);
put(writer, ")");
}
}
void main(){
import std.format : format;
assert( format("%s", Point!int(1,2)) == "(1, 2)");
import std.experimental.logger;
sharedLog.infof("%s", Point!int(1,2));
}
```
Pasting this into https://run.dlang.io/, it just works. That's
for DMD 2.099, so it might be a regression -- or recent feature?
-- Bastiaan.
Hi Bastiaan,
I think the cause is in some change happened in the logger
module, I'm recompiling some code with the latest dmd frontend.
I solved it simply using the 'logX' functions at module level
instead of the sharedLog methods.
Thank you!
toString best practices
Hello everybody,
Let's assume there's an implementation of a templated struct like
this:
```
import std.format, std.range.primitives;
struct Point(T)
{
T x, y;
void toString(W)(ref W writer, scope const ref
FormatSpec!char f) const
if (isOutputRange!(W, char))
{
put(writer, "(");
formatValue(writer, x, f);
put(writer, ", ");
formatValue(writer, y, f);
put(writer, ")");
}
}
void main(){
import std.format : format;
assert( format("%s", Point!int(1,2)) == "(1, 2)");
import std.experimental.logger;
sharedLog.infof("%s", Point!int(1,2));
/+
Error: none of the overloads of template
`std.logger.core.Logger.memLogFunctions!LogLevel.info.logImplf`
are callable using argument types `!()(string, Point!int) shared`
/Users/pinver/dlang/dmd-2.102.0/osx/bin/../../src/phobos/std/logger/core.d(828,14):
Candidates are: `logImplf(int line = __LINE__, string file = __FILE__,
string funcName = __FUNCTION__, string prettyFuncName = __PRETTY_FUNCTION__,
string moduleName = __MODULE__, A...)(lazy bool condition, lazy string msg,
lazy A args)`
/Users/pinver/dlang/dmd-2.102.0/osx/bin/../../src/phobos/std/logger/core.d(876,14):
`logImplf(int line = __LINE__, string file = __FILE__,
string funcName = __FUNCTION__, string prettyFuncName = __PRETTY_FUNCTION__,
string moduleName = __MODULE__, A...)(lazy string msg, lazy A args)`
+/
}
```
What is the best way to handle also shared writers?
Thank you all,
Paolo
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: Is @live attribute working yet?
On Sunday, 24 April 2022 at 12:21:29 UTC, elfstone wrote: On Sunday, 24 April 2022 at 11:36:29 UTC, Paolo Invernizzi wrote: On Sunday, 24 April 2022 at 09:31:40 UTC, elfstone wrote: [...] You need to use the flag `-preview=dip1021` test.d(8,30): Error: variable `test.test.p` assigning to Owner without disposing of owned value Weird, it's still not working here. I have tried the flag with dub, and dmd. You are right with 2.099.1, it seems to be included in the 2.100.0-beta.1 ... pinver@Moria test % /Users/pinver/dlang/dmd-2.099.1/osx/bin/dmd -preview=dip1021 -c -o- src/test.d pinver@Moria test % /Users/pinver/dlang/dmd-2.100.0-beta.1/osx/bin/dmd -preview=dip1021 -c -o- src/test.d src/test.d(8): Error: variable `test.test.p` assigning to Owner without disposing of owned value
Re: Is @live attribute working yet?
On Sunday, 24 April 2022 at 09:31:40 UTC, elfstone wrote:
Dub(DMD 2.099.1) builds and runs the following code without a
warning.
import std.stdio;
import core.stdc.stdlib;
@live
void test()
{
int* p = cast(int*) malloc(32);
p = cast(int*) malloc(32);
free(p);
}
void main()
{
test();
writeln("???");
}
Isn't it supposed to trigger an error according to the doc
(https://dlang.org/spec/ob.html)?
@live void test()
{
auto p = allocate();
p = allocate(); // error: p was not disposed of
release(p);
}
You need to use the flag `-preview=dip1021`
test.d(8,30): Error: variable `test.test.p` assigning to Owner
without disposing of owned value
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: Strong typing and physical units
On Tuesday, 28 July 2020 at 11:04:00 UTC, Cecil Ward wrote:
Of course, in C I used to do something like strong typing with
an opaque type achieved by using something like typedef struct
_something {} * type1; and then I had to do casting to get back
the real type, which was unchecked but it did prevent the user
from mixing up the types type1 and type2 say as they weren’t
assignment compatible.
I would really like strong typing to be a built in feature.
Would anyone else support this?
Once upon a time, typedef was present and backed by the compiler,
but nowadays you can find it in Phobos [1], but with some quirk
...
[1] https://dlang.org/phobos/std_typecons.html#.Typedef
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: D and Async I/O
On Monday, 11 May 2020 at 15:02:59 UTC, bauss wrote: On Monday, 11 May 2020 at 14:02:54 UTC, Russel Winder wrote: OK, so I need to create an asynchronous TCP server (not HTTP or HTTPS, this is a real server ;-) ). I think the normal response is "Use Vibe.d". However, recently I see Hunt is an alternative. Has anyone any way of choosing between the two? vibe.d is much more mature than Hunt, that would be my take on it. Also Hunt lacks documentation etc. I notice that Hunt uses it's own library eschewing all of Phobos. Is this an indicator that Phobos is not suitable for networking activity? std.socket is terrible, so yes that is an indicator. You can't even wrap something up fast in it either. Basically it's low-level while not being low-level at the same time. You have to handle __everything__ yourself pretty much. Have a look also to Martin std.io [1] and Steven iopipes [2], if you need something simple. [1] https://github.com/MartinNowak/io [2] https://code.dlang.org/packages/iopipe
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: Pattern matching via switch?
On Sunday, 15 March 2020 at 18:52:01 UTC, Steven Schveighoffer wrote: D doesn't support this natively. The closest you can get is something akin to what aliak wrote (you would need to write something, not sure if Phobos or some package has implemented the feature), or use cascaded if statements: I've just given a fast look at the thread, so maybe I'm wrong, but this [1] should be ok for pattern matching using plain and simple Phobos ... [1] https://dlang.org/phobos/std_variant.html#.visit
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: Cool name for Dub packages?
On Saturday, 7 March 2020 at 09:31:27 UTC, JN wrote: Do we have any cool name for Dub packages? Rust has 'crates' Crystal has 'shards' Python has 'wheels' Ruby has 'gems' Frankly, I simply hate all that shuffle around names ... it's so difficult to understand people when it's referring to them ...we already had to remember a gazillion on things, including horrible ubuntu names instead of simple numbers! :-) Packages are ... well packages! :-P /P
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: Meta question - what about moving the D - Learn Forum to a seperate StackExchange platform?
On Friday, 18 October 2019 at 11:45:33 UTC, Seb wrote: On Friday, 18 October 2019 at 10:55:59 UTC, Martin Tschierschke wrote: [...] In the state of the D survey, there were more people in favor of StackOverflow than D.learn, but to be fair the majority voted for "I don't care" https://rawgit.com/wilzbach/state-of-d/master/report.html Maybe it's possible to simply add an up/down vote functionality to the forum only, just keeping the compatibility with the newsgroup ... It's a win/win solution!
Re: Vibe.d Error
On Friday, 18 October 2019 at 08:06:30 UTC, Vino wrote: On Thursday, 17 October 2019 at 19:02:14 UTC, Vino wrote: [...] Hi Andre, I tried install vibe.d in SUSE linux 12 SP2 and facing the below error, tried the options as per the link https://github.com/vibe-d/vibe.d/issues/1748, still no luck and the lib's are installed in the server [...] The same here on macOS Catilina ... I'm too interested in a solution for that
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: Undefined symbol: _dyld_enumerate_tlv_storage (OSX)
On Monday, 14 October 2019 at 05:36:44 UTC, Joel wrote: On Friday, 11 October 2019 at 11:38:27 UTC, Jacob Carlborg wrote: [...] I get this since Catalina: Joel-Computer:VacSpace joelchristensen$ dub Failed to invoke the compiler dmd to determine the build platform: dyld: lazy symbol binding failed: Symbol not found: _dyld_enumerate_tlv_storage Referenced from: /usr/local/bin/dmd Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _dyld_enumerate_tlv_storage Referenced from: /usr/local/bin/dmd Expected in: /usr/lib/libSystem.B.dylib Joel-Computer:VacSpace joelchristensen$ I use Home Brew (brew upgrade dmd, and brew upgrade dub) Brew is only up to 2.087.1 at the moment - John Colvin seems to be the man that mantains dmd with brew. I confirm that DMD downloaded from the official script works like charms on Catilina. You can rely on that right now ...
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: ld errors in osx Catalina
On Wednesday, 9 October 2019 at 16:08:41 UTC, rikki cattermole wrote: On 09/10/2019 11:33 PM, David Briant wrote: [...] D as a native language links against libc, so using the system c compiler as the linker is a viable method to prevent having to look things up. Perhaps try ldc? That uses LLVM so may be better on OSX. Related: https://issues.dlang.org/show_bug.cgi?id=20019 Also those versions on homebrew look to be at least one version out of date. If ldc on homebrew doesn't work, you should try the versions on the main site (which has dmg's) https://dlang.org/download.html I confirm that ldc-1.18.0-beta2 works fine on mine Catalina, downloaded and activated with the official install script. /Paolo
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: D on ARM laptops?
On Thursday, 4 July 2019 at 01:01:03 UTC, Nicholas Wilson wrote: On Wednesday, 3 July 2019 at 20:49:20 UTC, JN wrote: Does anyone know if and how well D works on ARM laptops (such as Chromebooks and similar)? For example this one https://www.pine64.org/pinebook/ . Can it compile D? Obviously DMD is out because it doesn't have ARM builds. Not sure about GDC. How about LDC? Haven't tried on laptops, but I can't imagine it would be too different to RasPi which LDC worked fine on. We are using LDC on Jetson boards and it's working fine ...
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: I really don't understand DUB
On Sunday, 14 April 2019 at 20:51:10 UTC, Andre Pany wrote: On Sunday, 14 April 2019 at 19:46:41 UTC, Ron Tarrant wrote: [...] You are totally right, it should be more intuitive how to use dub. As far as I know if you do not specify in dub.json/dub.sdl what type of package you have (executable/library) dub make a guess. Is there an app.d it will default the targetType "executable", if not it will default the targetType "library". To solve your specify the targetType explicitly in your dub.sdl file. https://dub.pm/package-format-json.html#target-types Kind regards Andre The Zen of Python, rule number two: explicit is better than implicit ... I guess that just killing all that educated dub guess will turn dub into a much easier tool to grasp. - P
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: D Binding to GUI libraries
On Sunday, 21 October 2018 at 07:33:45 UTC, Russel Winder wrote: The GTK/Qt battle on Linux was won by GTK+2 hence GNOME over KDE as the default for Debian and Fedora. Whether this was right or wrong is left as a choice for the reader! Linux is not only the desktop, and Qt simply dominates in industrial, medical and automation sector, that's where the money is. Qt is pushing strongly on the embedded marked, bare metal or linux (kernel) based... - Paolo
Re: Truly @nogc Exceptions?
On Saturday, 20 October 2018 at 14:56:37 UTC, Mike Parker wrote: On Saturday, 20 October 2018 at 13:48:32 UTC, Paolo Invernizzi wrote: If `@nogc` could be relaxed for `new Error` exactly for that reason, pieces of Phobos could be turned `@nogc`... But I admit that that change would be controversial... https://github.com/dlang/DIPs/blob/master/DIPs/DIP1008.md Yep, you are right, of course... 8-/ /P
Re: D Binding to GUI libraries
On Saturday, 20 October 2018 at 14:24:56 UTC, Russel Winder wrote: On Sat, 2018-10-20 at 12:43 +, tide via Digitalmars-d wrote: […] I mean it *may* work, but that isn't the problem if the developers completely lack support for the platform. I can download Qt with prebuilt libraries and it works out of the box with MSVC. There's an obvious difference between the two developers support. As someone else said GTK look like ass on Windows, Qt is really the only crossplatform GUI API written in a native-compile-able language out there that gets most things right. I do not disagree, especially about GTK+ not really being available on Windows and macOS, it is fundamentally a Linux and UNIX framework – I think we can ignore the fact that macOS is sort of FreeBSD in this circumstance due to macOS. I'd agree Qt is a much better cross-platform GUI framework that GTK+. I've use it with Python very successfully – originally with PySide, then PyQt, but now back with PySide2. I tried QML with Go to move to native code from Python, but it didn't really work for me as yet, though some people gave me a few tips a few weeks back that I haven't followed up on as yet. wxWidgets seems still to be going though and wxPython is rising as a phoenix . I haven't really used them though but maybe the latest version is worth a whirl. I guess people doing Qt stuff really do work with C++ if they don't work with Python? I'd call this an opportunity for D. The trick has to be to automate the creation of the binding. I have to admit I do not know what the technique is for PySide2 but PyQt certainly has a system for generation of the binding. Of course, Rust https://github.com/rust-qt As a company that will be hosted in the QT booth at SPS IPC Drives 2018 in Nuremberg at the end of November, C++ dominates. We are calling a little D codebase from a QT application, but just to leverage some legacy old code. I've used PySide, years ago, but nowadays the performance of the C++ compilers, and the agility of QT Creator are closing the bridge for a fast edit/compile/test cycle... the big advantage of PySide is the tremendous amount of python libraries that you can use in your application. Said that, we are using QML, but I don't love it a lot... - Paolo
Re: Truly @nogc Exceptions?
On Thursday, 20 September 2018 at 17:14:12 UTC, Steven Schveighoffer wrote: On 9/20/18 12:24 PM, Adam D. Ruppe wrote: On Thursday, 20 September 2018 at 15:52:03 UTC, Steven Schveighoffer wrote: I needed to know what the slice parameters that were failing were. Aye. Note that RangeError is called by the compiler though, so you gotta patch dmd to make it pass the arguments to it for index. Ugh. I did a PR for this once but it got shot down because of an allegeded (without evidence btw) performance degradation. Ugh. Well, you can always override that. Just do the check yourself and throw the error you want ;) In my case, that's what I did anyway. I don't know how a performance problem can occur on an error being thrown anyway -- the process is about to end. -Steve If `@nogc` could be relaxed for `new Error` exactly for that reason, pieces of Phobos could be turned `@nogc`... But I admit that that change would be controversial... - Paolo
Re: Shared - Another Thread
On Thursday, 18 October 2018 at 21:14:54 UTC, Stanislav Blinov wrote: On Thursday, 18 October 2018 at 20:59:59 UTC, Erik van Velzen wrote: [...] Quite a simple reason: it was years ago, however old you are now you were younger and less experienced, and probably didn't understand something back then. [...] Then I don't know what to tell you. It literally talks about compiler forbidding unsafe operations and *requiring* you to go the extra mile, by just rejecting invalid code (something that Manu is proposing to forego!). But that's *code*, not logic. [...] Tangetially?! There's a whole section on writing `shared`-aware code (none of which would even compile today, I don't know if it's addressed in his errata). [...] Yeah, some of that never happened and never will. But that aside, none of it says "threading will be safe by default". It says "threading will be a lot less unsafe by default". And *that* is what we must achieve. The "threading will be a lot less unsafe by default" is related to the default TLS usage. I remember like Erik, maybe wrongly, that the ambitions on shared were more directed towards the "threading will be safe by default" goal. I've to read again some post from Bartosz Milewski... /Paolo
Error: non-shared method core.sync.condition.Condition.notify is not callable using a shared object
There's a rational behind the fact that there's not a 'shared' version of notify/wait method in Condition? Thanks, Paolo
Re: Shared - Another Thread
On Wednesday, 17 October 2018 at 21:55:48 UTC, H. S. Teoh wrote: The problem, of course, is that they are also charged particles, and the electromagnetic forces that hold the atom in place would be greatly disturbed if two atoms were to occupy the same space simultaneously, leading to a (very fast and very violent) reorganization of nucleii and electrons. What that looks like macroscopically, I can't say exactly, but certainly delicate structures like proteins, DNA, lipid layers, and such would cease to exist, their constituent particles being violently scattered every which way in the course of reorganizing themselves into new structures that would bring the electromagnetic forces back into balance (and that, in all likelihood, won't resemble anything close to their starting molecular structures). Whatever the result may be, I'm pretty certain it would not have good consequences for the biological processes built upon said delicate structures. To say the least. :-D Even worst than that: conversion to/from E is involved in the process! :-P
Re: shared - i need it to be useful
On Thursday, 18 October 2018 at 06:20:02 UTC, Manu wrote: On Wed, Oct 17, 2018 at 5:05 AM Timon Gehr via Digitalmars-d wrote: [... all text ...] OMFG, I just spent about 3 hours writing a super-detailed reply to all of Timon's posts in aggregate... I clicked send... and it's gone. I don't know if this is a gmail thing, a mailing list thing... no idea... but it's... gone. I can't repeat that effort :( Never never write something super-detailed in a web-based "thing"! Native application, and copy-past! :-O But' now I'm curious about your reply! Timon argumentation are really strong (IMHO), so it's a double effort! :-/ /Paolo
Re: My statements related to terminating my SAoC relationship
On Wednesday, 17 October 2018 at 20:03:23 UTC, lagfra wrote: On Monday, 15 October 2018 at 21:26:52 UTC, solidstate1991 wrote: I have done two mistakes: I underestimated the scope of the project and overestimated my capabilities. This caused a chain reaction, which in turn made the first milestone unreachable. Hi, I'm one of the other participants to the SAoC project and I'm replying on behalf of me and Francesco, the other SAoC student. We just wanted to tell you not to be too hard on yourself and that we understand the difficult time you're going through. Also, if you want a change of air or a place were you can look for new opportunities, we both are students in Turin (Italy) right now and you're welcome to join us anytime. We hope the best for you. I agree with lagfra, take your time... BTW, it seems that the Italian D Programmers League is more crowded that expected... /Paolo
Re: Deep nesting vs early returns
On Saturday, 6 October 2018 at 18:55:48 UTC, Patrick Schluter wrote: On Saturday, 6 October 2018 at 05:36:59 UTC, Paolo Invernizzi wrote: [...] In the 90s I used to add the C preprocessor to other languages which lacked efficient constant definition (i.e. compile time constructs). AutoLISP, the LISP dialect used to write application in AutoCAD. There were nearly a 100 of small programs in different files and throughout the whole project there were a lot repetitions that could not be factorized with AutoCAD means. Include, define and ifdef allowed to do things, that were very difficult to do at that time (it was on AutoCAD v9.0 which had only 64K memory for the LISP code). I also added the C preprocessor to the DBASE III and the compatible MS-DOS based Foxbase. Fox, the speediest indexes in the country... what a time! :-P /P
Re: Deep nesting vs early returns
On Friday, 5 October 2018 at 19:04:26 UTC, Nick Sabalausky (Abscissa) wrote: On 10/04/2018 11:40 PM, rikki cattermole wrote: [...] It's not *my* statement about newer/older. If you recall the programming atmosphere around 2000, OO was widely being touted as a newer thing, superior to "old-fashioned" imperative, even though there's a million things about that whole assessment that are false (not the least of which being the at-the-time popular notion that Java-style OO somehow wasn't still imperative, or, as you pointed out, that OO was a new invention). There's one minor aspect of it that was true though: Widespread popularity of OO was certainly a new thing, even if OO itself wasn't. The hype was hight also in the 90... I remember having used (in production!) a 3rd party extension to Clipper (I don't remember if Summer 87, or 5.0.x) that added OO to the language! 0__o /Paolo
Re: DIP 1014
On Thursday, 4 October 2018 at 08:10:31 UTC, Shachar Shemesh wrote: On 04/10/18 11:05, Stanislav Blinov wrote: On Thursday, 4 October 2018 at 03:06:35 UTC, Shachar Shemesh wrote: [...] For the love of Pete, that program was an example of how a move hook should work, *not* a demonstration of achieving the DIP behavior without changing the language. I know the example is brittle and have said as much. The example isn't brittle. It is simply not an example. If you want to leave it out, however, then I think you should submit an orderly proposal. The changes you seem to be suggesting have consequences that go beyond what I think you understand, and there can be no serious discussion of it while it is not clear from your posts which part of what you say is the relevant one. Shachar While I want to thank you both, about the quality of this thread, what kind of "consequences that go beyond what I think you understand" are you thinking of? Can you give an example? Thanks, Paolo
Re: OT: Bad translations
On Thursday, 27 September 2018 at 07:03:51 UTC, Andrea Fontana wrote: On Thursday, 27 September 2018 at 05:15:01 UTC, Ali Çehreli wrote: A delicious Turkish desert is "kabak tatlısı", made of squash. Now, it so happens that "kabak" also means "zucchini" in Turkish. Imagine my shock when I came across that desert recipe in English that used zucchini as the ingredient! :) Ali You can't even imagine how many italian words and recipes are distorted... Andrea +1 :-P
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
