DIP 1014
Who knows about DIP 1014? (struct move hook) Is it well received? Is it likely to be accepted soon? I'm working on the std::string binding, it's almost finished... but then I hit a brick wall. GNU's std::string implementation stores an interior pointer! >_< No other implementation does this. It's a really bad implementation actually, quite inefficient. It could make better use of its space for small-strings if it wasn't wasting 8-bytes for an interior pointer to a small string buffer... Anyway, I'm blocked until this DIP is accepted; so, is it looking promising?
Re: Prevent opening binary/other garbage files
On Saturday, 29 September 2018 at 23:46:26 UTC, helxi wrote: Thanks. Would you say https://dlang.org/library/std/encoding/get_bom.html is useful in this context? Eh, not really, most text files will not have one.
Re: Updating D beyond Unicode 2.0
On Saturday, 29 September 2018 at 16:19:38 UTC, ag0aep6g wrote: On 09/29/2018 04:19 PM, Shachar Shemesh wrote: On 29/09/18 16:52, Dukc wrote: [...] I know you meant Sarn, but still... can you please be a bit less aggresive with our wording? From the article (the furthest point I read in it): When I ask myself what I've found life is too short for, the word that pops into my head is "bullshit." Dukc didn't post that link. sarn did. You are 100% correct. My most sincere apologies. I am going to stop responding to this thread now. Shachar
Re: Prevent opening binary/other garbage files
On Saturday, 29 September 2018 at 16:01:18 UTC, Adam D. Ruppe wrote: On Saturday, 29 September 2018 at 15:52:30 UTC, helxi wrote: I'm writing a utility that checks for specific keyword(s) found in the files in a given directory recursively. What's the best strategy to avoid opening a bin file or some sort of garbage dump? Check encoding of the given file? Simplest might be to read the first few bytes (like couple hundred probably) and if any of them are < 32 && != '\t' && != '\r' && != '\n' && != 0, there's a good chance it is a binary file. Text files are frequently going to have tabs and newlines, but not so frequently other low bytes. If you do find a bunch of 0's, but not the other values, you might have a utf-16 file. Thanks. Would you say https://dlang.org/library/std/encoding/get_bom.html is useful in this context?
[Issue 19260] extern(C++) `T* const` mangling
https://issues.dlang.org/show_bug.cgi?id=19260 --- Comment #6 from Manu --- Of course! This is MS after all! This is not the first time this class of issue has emerged however, but in this case, I'm powerless to make any change to help... --
[Issue 19260] extern(C++) `T* const` mangling
https://issues.dlang.org/show_bug.cgi?id=19260 --- Comment #5 from ki...@gmx.net --- Well, as shown, D is flexible enough to overcome crappy situations like this, albeit in cumbersome ways. Just saying that I don't think it's worthwhile to come up, implement and document solutions to exotic problems like this, which could also be tackled on the C++ side. I take it you cannot simply add another C++ template, as that one probably doesn't get instantiated on the C++ side, and aren't willing to hack the STL either. Btw, cppreference says the signature is `T*` [https://en.cppreference.com/w/cpp/memory/allocator/deallocate], so does MS have to go its own route once again? ;) --
[Issue 19260] extern(C++) `T* const` mangling
https://issues.dlang.org/show_bug.cgi?id=19260 --- Comment #4 from Manu --- But it's impossible to link. That's really important... --
[Issue 19260] extern(C++) `T* const` mangling
https://issues.dlang.org/show_bug.cgi?id=19260 --- Comment #3 from ki...@gmx.net --- I don't think there's a need for a proper solution for this on the D side: 1) `T* const` is rare in my experience. 2) This `const` affecting the C++ mangle is a big mistake IMO. The caller can't care less about it, it's just an implementation detail of the callee (not gonna mutate the param, i.e., my private pointer copy) leaking to the outside world and causing issues like this. --
[Issue 19260] extern(C++) `T* const` mangling
https://issues.dlang.org/show_bug.cgi?id=19260 --- Comment #2 from Manu --- I have used that hack to move forward... but it's not a reasonable solution. --
Re: lodash like utility/algorithms library for D
On Saturday, 29 September 2018 at 12:40:14 UTC, aliak wrote:
I.e. by allowing you to define the unexepcted you could for
instance:
enum JSONError {
invalidKey, notString, notNumber
}
auto a = parse(jsonData);
a.getAsString("key").match!(
(string value) => // yay
(JSONError error) => // small domain of what went wrong
);
I agree that this is useful, but why not just return a naked
`SumType!(string, JSONError)` in that case? Is there some
additional value added by the `Expect` wrapper that I'm not
seeing?
LDC 1.12.0-beta2 (based on LLVM 7)
Glad to announce the second beta for LDC 1.12. * Based on D 2.082.0+ (today's DMD stable). * Support for LLVM 7, which is used for the prebuilt packages. Due to an LLVM 7.0.0 regression, the prebuilt x86[_64] LDC binaries require a CPU with SSSE3. * New, Easy::jit-like interface for dynamic/JIT compilation. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.12.0-beta2 Thanks to all contributors!
[Issue 19249] Trying to build DMD for windows with LDC fails
https://issues.dlang.org/show_bug.cgi?id=19249 --- Comment #4 from ki...@gmx.net --- Should be working with LDC v1.12-beta2 again. --
Re: Quick C bindings
On Friday, 28 September 2018 at 16:39:14 UTC, Márcio Martins wrote: Hi y'all! If you'd be so kind and help me out here with a few questions/opinions: I would like to generate decent D bindings for https://github.com/libuv/libuv with as little pain as possible. What are you guys using these days to generate bindings? I remember trying Dstep a few years ago, but it didn't work very well for me at the time. What's new in this regard? I've been using the ones in dlang.org but have run into some issues, and would like to include bindings as part of my project, if it's not too painful. What is the state of shared libraries on the various platforms/compilers? I remember they were not supported everywhere and by all compilers, as this been addressed? Dstep has got better. Give it a try now.
Re: vibe.d error
On Friday, 28 September 2018 at 11:08:57 UTC, Sebastiaan Koppe wrote: On Thursday, 27 September 2018 at 17:37:43 UTC, hridyansh thakur wrote: [snip] What version of dmd do you use? i am using ldc and gdc not dmd LDC - the LLVM D compiler (1.11.0git-054d933): based on DMD v2.081.0 and LLVM 6.0.1 built with LDC - the LLVM D compiler (1.11.0git-054d933) Default target: x86_64-pc-windows-msvc Host CPU: skylake http://dlang.org - http://wiki.dlang.org/LDC
[Issue 18955] extern(C++) default struct mangling is overridden when interacting with a `cppmangle = class` template
https://issues.dlang.org/show_bug.cgi?id=18955 --- Comment #9 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/a1a87203a1f01c79a96ffbc1a45cece2fed6501e add test for issue 18955 https://github.com/dlang/dmd/commit/00f4c42c92da7fd590a8edf8dc6c6562fe988fe4 Merge pull request #8708 from rainers/test_18955 add test for issue 18955 merged-on-behalf-of: Petar Kirov --
Re: Updating D beyond Unicode 2.0
On 09/29/2018 04:19 PM, Shachar Shemesh wrote: On 29/09/18 16:52, Dukc wrote: [...] I know you meant Sarn, but still... can you please be a bit less aggresive with our wording? From the article (the furthest point I read in it): When I ask myself what I've found life is too short for, the word that pops into my head is "bullshit." Dukc didn't post that link. sarn did.
Re: Prevent opening binary/other garbage files
On Saturday, 29 September 2018 at 15:52:30 UTC, helxi wrote: I'm writing a utility that checks for specific keyword(s) found in the files in a given directory recursively. What's the best strategy to avoid opening a bin file or some sort of garbage dump? Check encoding of the given file? Simplest might be to read the first few bytes (like couple hundred probably) and if any of them are < 32 && != '\t' && != '\r' && != '\n' && != 0, there's a good chance it is a binary file. Text files are frequently going to have tabs and newlines, but not so frequently other low bytes. If you do find a bunch of 0's, but not the other values, you might have a utf-16 file. If so, what are the most popular encodings (in POSIX if that matters) and how do I detect them? for text on posix computers they are likely going to be utf8, and you can try using Phobos' readText function. It will throw if it encounters non-utf8, so you catch that and go on to the next one. But the simpler check described above will also probably work and can read less of the file.
Re: lodash like utility/algorithms library for D
On Saturday, 29 September 2018 at 12:44:38 UTC, aliak wrote: On Saturday, 29 September 2018 at 01:40:34 UTC, Robby Marki wrote: On Friday, 28 September 2018 at 14:02:48 UTC, aliak wrote: [...] In this example https://aliak00.github.io/ddash/ddash/functional/try_.html where does the match function come from? I get this error when trying to compile: onlineapp.d(16): Error: no property match for type int /dlang/dmd/linux/bin64/../../src/phobos/std/algorithm/iteration.d(500): instantiated from here: MapResult!(__lambda1, int[]) onlineapp.d(15):instantiated from here: map!(int[]) Haha ok I'm a bit stumped right now. That example is wrong, so you get the correct error, but it actually compiles on me machine right now. I changed Try.front to return the expected return value of a tryable function. And in that example that would clearly be an int. So there is no "match" on type int is what I should be seeing as well. But for some reason that I'm going to have to dig in to, it's compiling a running in the actual project code O_o. Sorry no, it is working as expected. I see that you have an error on onlineapp.d(16) ... are you using run.dlang.io? I just tried a new project and it compiles fine. Match is part of the Try type. Cheers, - Ali
Prevent opening binary/other garbage files
I'm writing a utility that checks for specific keyword(s) found in the files in a given directory recursively. What's the best strategy to avoid opening a bin file or some sort of garbage dump? Check encoding of the given file? If so, what are the most popular encodings (in POSIX if that matters) and how do I detect them?
Re: Updating D beyond Unicode 2.0
On 29/09/18 16:52, Dukc wrote: On Saturday, 29 September 2018 at 02:22:55 UTC, Shachar Shemesh wrote: I missed something he said in one of the other (as of this writing, 98) posts of this thread, and thus causing Dukc to label me a bullshitter. I know you meant Sarn, but still... can you please be a bit less aggresive with our wording? From the article (the furthest point I read in it): When I ask myself what I've found life is too short for, the word that pops into my head is "bullshit." That is the word used by the article *you* linked to, in reference to me. If it offends you enough to be accused of *calling* someone that, just imagine how I felt being *called* that very same name. Seriously, I don't make it a habit of being offended by random people on the Internet, but this is more a conscious decision than a naturally thick skin. Seeing that label hurt. Don't worry. I've been on the Internet since 1991. That's longer than the median age here (i.e. - I've been on the Internet since before most of you have been born). I've had my own fair share of flame wars, include some that, to my chagrin, I've started. In other words, I got over it. I did not reply, big though the temptation was. But the right time to be sensitive about what words are being used was *before* you linked to the article. Taking offense from being called out for calling someone something you find offensive is hypocritical. I never understood the focus on words. It's not the use of that word that offended me, it's the fact that you thought anything I did justified using it. I don't think using "cattle excrement" instead would have been any less hurtful. And it's not that the rest of your post was thoughtful, considerate and took pains to give constructive criticism, with or without hurting anyone's feelings. It's just that it doesn't seem to be that part bothers you. Shachar
Re: Updating D beyond Unicode 2.0
On Saturday, 29 September 2018 at 02:22:55 UTC, Shachar Shemesh wrote: I missed something he said in one of the other (as of this writing, 98) posts of this thread, and thus causing Dukc to label me a bullshitter. I know you meant Sarn, but still... can you please be a bit less aggresive with our wording?
[Issue 19275] std.process: redirecting output in a non-console application fails
https://issues.dlang.org/show_bug.cgi?id=19275 Rainer Schuetze changed: What|Removed |Added Keywords||pull --- Comment #1 from Rainer Schuetze --- https://github.com/dlang/phobos/pull/6722 --
[Issue 19275] std.process: redirecting output in a non-console application fails
https://issues.dlang.org/show_bug.cgi?id=19275 Rainer Schuetze changed: What|Removed |Added Summary|st.process: redirecting |std.process: redirecting |output in a non-console |output in a non-console |application fails |application fails --
[Issue 19275] New: st.process: redirecting output in a non-console application fails
https://issues.dlang.org/show_bug.cgi?id=19275
Issue ID: 19275
Summary: st.process: redirecting output in a non-console
application fails
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: r.sagita...@gmx.de
When linking a Windows application with the Microsoft runtime 12 or earlier,
running a process and redirecting its output fails:
import std.process;
import core.sys.windows.windows;
extern(C) int main(string[] args)
{
try
{
auto res = execute(["dmd.exe", "--version"], null,
Config.suppressConsole);
MessageBoxA(null, res.output.ptr, "OK", MB_OK);
}
catch(Throwable e)
{
MessageBoxA(null, e.msg.ptr, "EXCEPTION", MB_OK);
}
return 0;
}
alias extern(C) int function(string[] args) MainFunc;
extern (C) int _d_run_main(int argc, char **argv, MainFunc mainFunc);
extern (Windows)
int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int
nCmdShow)
{
return _d_run_main(0, null, ); // arguments unused, retrieved via
CommandLineToArgvW
}
causes an exception when built with `dmd -m64 redir.d -L/Subsystem:windows
user32.lib` against VS2013. Works with -m32 or VS2015 and VS2017.
--
Re: lodash like utility/algorithms library for D
On Saturday, 29 September 2018 at 01:40:34 UTC, Robby Marki wrote: On Friday, 28 September 2018 at 14:02:48 UTC, aliak wrote: Hi, I've been working for fun on a library [0] that is inspired by a library from the javascript world called lodash [1]. I basically liked the flexibility and thought I'd try and implement a few things as it was about the time I started learning D. It basically tried to do the same with algorithms as in lodash but adds the usage of Optional!T and Expect!(T, U) as ways to returns results. [...] In this example https://aliak00.github.io/ddash/ddash/functional/try_.html where does the match function come from? I get this error when trying to compile: onlineapp.d(16): Error: no property match for type int /dlang/dmd/linux/bin64/../../src/phobos/std/algorithm/iteration.d(500): instantiated from here: MapResult!(__lambda1, int[]) onlineapp.d(15):instantiated from here: map!(int[]) Haha ok I'm a bit stumped right now. That example is wrong, so you get the correct error, but it actually compiles on me machine right now. I changed Try.front to return the expected return value of a tryable function. And in that example that would clearly be an int. So there is no "match" on type int is what I should be seeing as well. But for some reason that I'm going to have to dig in to, it's compiling a running in the actual project code O_o.
Re: lodash like utility/algorithms library for D
On Friday, 28 September 2018 at 17:33:04 UTC, Paul Backus wrote:
On Friday, 28 September 2018 at 14:02:48 UTC, aliak wrote:
Hi,
[...]
Lots of good stuff here!
I'm curious about your approach to `Expect`, since I've written
a version of it myself. How useful have you found being able to
use unexpected values of any type, as opposed to just
exceptions?
Thanks! Still all rough around the edges.
About Expect, I've found that being able to define a set of
expected unexpected values is quite practical, and if they're all
based on the class Exception then there're two problems. 1, it's
a class so it comes with all those constraints. 2, there's no way
to close the value domain over the unexpeceted (if that makes
sense?). Also some functions (take the classic errono catastrophy
in C) may want to return error codes as unexpected values that
are ints, and at the same time have a valid value as an int as
well.
I.e. by allowing you to define the unexepcted you could for
instance:
enum JSONError {
invalidKey, notString, notNumber
}
auto a = parse(jsonData);
a.getAsString("key").match!(
(string value) => // yay
(JSONError error) => // small domain of what went wrong
);
A bit contrived here, but it actually comes form production code
(https://github.com/schibsted/account-sdk-ios/blob/master/Source/Core/JSON/JSONObject.swift).
Different language of course, but in that repo there's a type
called Result, which is basically Expect. But in swift you have
something called protocols, which lets you contstrain template
types (in a different way than isInputRange works). And there's a
standard protocol called Error. So you can do:
Result where JSONError is defined as:
struct JSONError: Error {} // conforms to error protocol.
There's actually a D DIP which could allow for similar behavior:
https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md
But for now since D does not have that.
Another approach would be duck typying I guess. And make a
isExceptionType trait in D that makes sure some functions are
supported (i.e. msg, and that it can be constructed with
__FILE__, __LINE__ ). I have not thought out completely how those
semantics would work, just thinking out loud right now.
Re: Quick C bindings
On Friday, 28 September 2018 at 16:44:31 UTC, Adam D. Ruppe wrote: What, exactly do you want to do with them? Using them is well-supported, but creating them is more iffy. Create/load/unload. I want to create a hot-reload workflow of smaller components of my projects, since compilation times are becoming an issue, even with DMD, and each developer works on quite contained "sub-modules".
Re: Quick C bindings
On Friday, 28 September 2018 at 21:42:25 UTC, bachmeier wrote: If they're pure C, you can use dpp: https://github.com/atilaneves/dpp Even if you want to work with the bindings, not just call the C functions, you can use the intermediate files that dpp creates. It works with pretty much everything I've thrown at it. Thanks! Definitely sounds promising. Will give a go!
[Issue 12694] Better error message for function call matching more than two overloads
https://issues.dlang.org/show_bug.cgi?id=12694 wolframw changed: What|Removed |Added Status|NEW |ASSIGNED CC||wolfr...@protonmail.com Assignee|nob...@puremagic.com|wolfr...@protonmail.com --
Re: Funny way to crash dmd and brick the whole computer
On Friday, 28 September 2018 at 11:58:25 UTC, Zardoz wrote:
CTE fib :
module fib_cte;
import std.stdio;
long fib(long n) {
if (n <= 1) return 1;
return fib(n - 1) + fib(n - 2);
}
static immutable valueFib = fib(46);
void main() {
writeln(valueFib);
}
What exactly did you expect?
Re: Delegates with stackpointers
On Saturday, 29 September 2018 at 06:01:50 UTC, Ritchie wrote: How does a delegate with a stackpointer work? e.g. in this example: https://run.dlang.io/is/XviMSl Does the second call to foo not overwrite the stack of the first call and thereby the data pointed to by bar1? How is that data preserved? In this case "a" will not live on the stack of "foo". This can be proved by: Shows all variables in "sequence: (Because "a" is not used within the delegate.) https://run.dlang.io/is/mwopBi Shows only "b" and "c" in sequence: https://run.dlang.io/is/c0rpO8
Re: Delegates with stackpointers
On Saturday, 29 September 2018 at 06:01:50 UTC, Ritchie wrote:
How does a delegate with a stackpointer work? e.g. in this
example:
https://run.dlang.io/is/XviMSl
Does the second call to foo not overwrite the stack of the
first call and thereby the data pointed to by bar1? How is that
data preserved?
Why should a call to foo overwrite something? Aren't these two
foos equivalent from this point of view?
´´´
DelegateT foo1() {
int a = 0;
void bar() {
a++;
writeln(a);
}
return
}
auto foo2()
{
struct S
{
int a;
void opCall()
{
a++;
writeln(a);
}
}
return S.init;
}
´´´
Delegates with stackpointers
How does a delegate with a stackpointer work? e.g. in this example: https://run.dlang.io/is/XviMSl Does the second call to foo not overwrite the stack of the first call and thereby the data pointed to by bar1? How is that data preserved?
