Re: Silicon Valley D Meetup November 19, 2015
On Friday, 20 November 2015 at 08:10:26 UTC, Ali Çehreli wrote: - deadalnix was there, who is always a great person to have around both technically and friendshippally. :p I'd like to add that Ali was there, and he is also a great person to have around :)
Re: Calypso progress report (+ updated MingW64 build)
On Monday, 23 November 2015 at 23:33:21 UTC, Elie Morisse wrote: On Monday, 23 November 2015 at 00:04:44 UTC, deadalnix wrote: I'd be very interested by the LLVM IR that this spout out. Here's the IR for https://github.com/Syniurge/Calypso/blob/master/tests/calypso/eh/std_exception.d : https://paste.kde.org/pjxrqjjhp Also, good work, pulling that one is hard. It wasn't that hard to be honest, I took many shortcuts thanks to Clang and Calypso. But even without them it's doable. About the issue you mentioned in the other thread, I don't think generating std::type_info values will be too big of a hindrance for Walter. Looking at cxxabi.h the classes derived from type_info all have simple layouts so generating values at least for classes singly inheriting from std::exception should be achievable without too much sweat. Yeah that's what I wanted to look int he IR. Where is _D_ZTISt9exception7__tiwrap defined ? Looks like you trimed the output :(
Re: let (x,y) = ...
On Monday, 23 November 2015 at 22:32:57 UTC, visitor wrote: On Monday, 23 November 2015 at 20:10:49 UTC, visitor wrote: Andrea Fontana(s allows let (hello, world) = ["hi", "there", "!"]; of course in your version let (hello, world)[] = ["hi", "there", "!"] works but for consistency with range, i think Fontana's note is relevant Well, I believe it's a matter of taste. By allowing different number of elements there you allow more errors to sink in without gaining anything at all. You lose the choice between strict and loose operators, erase the difference. It's not the "consistency" I would like to have.
Re: Calypso progress report (+ updated MingW64 build)
On Monday, 23 November 2015 at 00:04:44 UTC, deadalnix wrote: I'd be very interested by the LLVM IR that this spout out. Here's the IR for https://github.com/Syniurge/Calypso/blob/master/tests/calypso/eh/std_exception.d : https://paste.kde.org/pjxrqjjhp Also, good work, pulling that one is hard. It wasn't that hard to be honest, I took many shortcuts thanks to Clang and Calypso. But even without them it's doable. About the issue you mentioned in the other thread, I don't think generating std::type_info values will be too big of a hindrance for Walter. Looking at cxxabi.h the classes derived from type_info all have simple layouts so generating values at least for classes singly inheriting from std::exception should be achievable without too much sweat.
Re: let (x,y) = ...
On Monday, 23 November 2015 at 20:10:49 UTC, visitor wrote: Andrea Fontana(s allows let (hello, world) = ["hi", "there", "!"]; of course in your version let (hello, world)[] = ["hi", "there", "!"] works but for consistency with range, i think Fontana's note is relevant
Re: https everywhere!
On Monday, 23 November 2015 at 21:18:58 UTC, Walter Bright wrote: The widgets don't, but the forums worked when I tried it. Firefox 42.0 here, neither the widgets nor the forums worked.
Re: https everywhere!
On 11/23/2015 1:11 PM, Adam D. Ruppe wrote: On Monday, 23 November 2015 at 20:55:32 UTC, Walter Bright wrote: I'm pleased to announce that Jan Knepper has gotten us some proper certificates now, and dlang.org and digitalmars.com are now fully https! So it isn't actually https everywhere. On a https page, the browsers by default block any external asset which itself isn't https loaded. The forum and TWID widgets are not https and now no longer load on the homepage :( The widgets don't, but the forums worked when I tried it.
Re: https everywhere!
On Monday, 23 November 2015 at 20:55:32 UTC, Walter Bright wrote: I'm pleased to announce that Jan Knepper has gotten us some proper certificates now, and dlang.org and digitalmars.com are now fully https! So it isn't actually https everywhere. On a https page, the browsers by default block any external asset which itself isn't https loaded. The forum and TWID widgets are not https and now no longer load on the homepage :(
https everywhere!
I'm pleased to announce that Jan Knepper has gotten us some proper certificates now, and dlang.org and digitalmars.com are now fully https!
Re: let (x,y) = ...
On Monday, 23 November 2015 at 18:38:45 UTC, thedeemon wrote: let (hello, world)[] = arr; i think what Andrea Fontana is talking is the other way around your solution allows let (hello, world)[] = ["hi"]; Andrea Fontana(s allows let (hello, world) = ["hi", "there", "!"];
Re: let (x,y) = ...
On Monday, 23 November 2015 at 16:58:43 UTC, Andrea Fontana wrote: Nice. Why first enforce is "==" rather than ">=" ? This prevents something like: auto arr = ["hello", "world", "!"]; let (hello, world) = arr; The very first post of this thread should have answered this. Two options are available: one requires exact number of elements and so catches more errors, the other requires there to be "enough" data, for cases where you want that. To get behavior you described just use let (hello, world)[] = arr;
Re: let (x,y) = ...
On Monday, 23 November 2015 at 16:58:43 UTC, Andrea Fontana wrote: Nice. Why first enforce is "==" rather than ">=" ? This prevents something like: auto arr = ["hello", "world", "!"]; string hello; string world; let (hello, world) = arr; note that this is thedeemon's work ! (sorry couldn't resist) anyway, yes indeed !
Re: let (x,y) = ...
On Monday, 23 November 2015 at 11:12:33 UTC, visitor wrote:
this work fine with your unittest :
auto let(Ts...)(ref Ts vars) {
struct Let
{
void opAssign( Tuple!Ts xs ) {
foreach(i, t; Ts)
vars[i] = xs[i];
}
static if (sameTypes!Ts) {
import std.conv : text;
void opAssign(Ts[0][] xs) { // redundant but more
effective
enforce(xs.length == Ts.length, "let (...) =
...: array must have " ~ Ts.length.text ~ " elements.");
foreach(i, t; Ts)
vars[i] = xs[i];
}
void opAssign(R)(R xs) if (isInputRange!R &&
is(ElementType!R == Ts[0])) {
static if (hasLength!R) {
enforce(xs.length >= Ts.length, "let (...)
= ...: range must have at least " ~ Ts.length.text ~ "
elements.");
}
foreach(i, t; Ts) {
enforce(!xs.empty, "let (...) = ...: range
must have at least " ~ Ts.length.text ~ " elements.");
vars[i] = xs.front;
xs.popFront();
}
}
void opIndexAssign(R)(R xs) if (isInputRange!R &&
is(ElementType!R == Ts[0])) {
foreach(i, t; Ts) {
if(xs.empty) return;
vars[i] = xs.front;
xs.popFront();
}
}
}
}
return Let();
}
Nice. Why first enforce is "==" rather than ">=" ? This prevents
something like:
auto arr = ["hello", "world", "!"];
string hello;
string world;
let (hello, world) = arr;
Re: let (x,y) = ...
On Monday, 23 November 2015 at 14:54:15 UTC, thedeemon wrote: Yep, this way it works too, by capturing input vars in a closure. So the main difference is that your variant allocates GC memory while original variant does not allocate anything in the heap (only on stack). Thanks for clarifying :-) hope this will end into the language ! great work.
Re: LDC 0.17.0 alpha cross-compiler for Android/ARM, D 2.068.2
On Thursday, 12 November 2015 at 02:51:46 UTC, Jakob Ovrum wrote: The issues I had came with using the 64-bit NDK - it worked as explained in the article once I switched to the 32-bit NDK. The issue appeared to be with the linker: /usr/bin/ld.bfd would complain that it was not configured for --sysroots. Changing to --fuse-ld=mcld revealed further issues. Perhaps the wiki article should recommend the 32-bit NDK until these issues are figured out. I recently signed up for a linux/x64 VPS, so I've put a linux/x64 cross-compiler build at the above github link. You'll need to set a NDK_ARCH environment variable to x86_64, to use the 64-bit NDK with the updated ldc patch and sample commands from the wiki. I don't package libconfig with this one, so it will need to be installed in the system, along with zlib. I had no problem with the 64-bit NDK once I made these changes, let me know if this works for you. Your problem could be because it's trying to use the system linker at /usr/bin/ld.bfd, rather than the one that came with the NDK?
Re: let (x,y) = ...
On Monday, 23 November 2015 at 11:12:33 UTC, visitor wrote: My original solution remembers in the constructor addresses of variables to fill, then does the filling in opAssign operator, so I needed a way to store the references and used pointers for that. yes, but you are using ref : "auto let(Ts...)(ref Ts vars)" so vars are changed, no need to store anything, no? i was wondering if there is some subtleties or efficiency reasons for using pointers Thanks for the code! Yep, this way it works too, by capturing input vars in a closure. So the main difference is that your variant allocates GC memory while original variant does not allocate anything in the heap (only on stack).
Re: [OT] bitcoin donation
On Monday, 23 November 2015 at 12:11:36 UTC, Steven Schveighoffer wrote: One could ask the same thing about any currency that isn't the one accepted at a store. Sure, online is much less of a hassle, but it's still a little time to sign up and administer. Is that much of Ali's time worth spending for at least three donations, likely more? I bet it would be. I looked with a tinge of fascination at what bitcoin was a while ago. I think there is a natural averse reaction to something that is valuable but that you cannot understand. --snip-- I know bitcoin has real math and genius behind it, and this is a silly example, but for those who do not understand how it actually works (including myself), it seems very similar in nature. Dollars (or whatever local currency you use) are understandable, and generally accepted at places where I shop. It's easy to see how one cannot duplicate them without evidence of doing so (the fundamental characteristic of currency). Online bits don't seem so uncopyable. I'm by no means steeped in the tech, but it's pretty straightforward to understand the broad strokes. It's just a giant distributed ledger with some crypto to keep it secure and hashing to avoid double-counting, ie the duplication you're worried about. But ultimately that doesn't really matter, as almost nobody knows how Dollars or other local currencies are created or what makes them tough to copy either. ;) All that matters for a currency is that many buyers and sellers will accept it, or at least exchange it quickly and easily for your currency of choice, and bitcoin certainly passes that bar.
Re: The D Language Foundation has $5000 to its name
On Monday, 23 November 2015 at 08:33:10 UTC, Vladimir Panteleev wrote: On Monday, 23 November 2015 at 04:37:18 UTC, Dicebot wrote: And how about GPG signing of releases which comes free and actually helps? :P When you hover over any of the download links on http://dlang.org/download.html, a corresponding .sig link will appear. Is this not what you're referring to? Whoa, this must be pretty new. Though subkey used seems to be almost 1 year old now. sub rsa4096/12BB1939 2015-02-27 That is very cool, though decision to put the mention of .sig into hover hint is weird :) I'll sign the key in that case, should start building some trust web.
Re: The D Language Foundation has $5000 to its name
On Sunday, 22 November 2015 at 21:45:06 UTC, Brad Anderson wrote: 1. SSL certificate for dlang.org (optionally getting an EV certificate would be a good way to advertise the Foundation in the address bar). With https://letsencrypt.org/ launching very soon, it might not be necessary to pay for a SSL certificate. BTW, Certum also offers very cheap (~$20 last I checked) personal Windows code-signing certificates for open source projects. The publisher will say "FirstName LastName, Open Source Developer", so probably not applicable to D.
Re: [OT] bitcoin donation
On 11/21/15 2:06 AM, Joakim wrote: On Tuesday, 10 November 2015 at 17:23:08 UTC, Steven Schveighoffer wrote: On 10/30/15 3:29 AM, Joakim wrote: But I don't see how bitcoin is similar to any of those, perhaps you have _some_ explanation? You don't have to keep the bitcoin, all those sites will buy your bitcoin with dollars anytime you want. It's just an open way to trade value- in your case, just another payment/donation method- I don't see the issue. If it required setting up a bunch of software, sure, but those websites make it easy to set up, as they run the client for you. Begging the question, why not trade your bitcoin for dollars and buy it using those? Simple, we're already invested in bitcoin: why waste money changing payment methods again, especially since it would be so easy for him to accept this new payment method? One could ask the same thing about any currency that isn't the one accepted at a store. I looked with a tinge of fascination at what bitcoin was a while ago. I think there is a natural averse reaction to something that is valuable but that you cannot understand. For example, if I told you that the phrase "jump in the fire" was valuable, and that you could accept it for payment, you would be hesitant to accept it I would imagine. Even if I explained that there were complicated algorithms behind it, and that some web sites would exchange this phrase for cash. Even if several experts and online articles explained how this is so. I know bitcoin has real math and genius behind it, and this is a silly example, but for those who do not understand how it actually works (including myself), it seems very similar in nature. Dollars (or whatever local currency you use) are understandable, and generally accepted at places where I shop. It's easy to see how one cannot duplicate them without evidence of doing so (the fundamental characteristic of currency). Online bits don't seem so uncopyable. -Steve
Re: let (x,y) = ...
On Monday, 23 November 2015 at 10:28:53 UTC, thedeemon wrote:
On Sunday, 22 November 2015 at 18:47:34 UTC, visitor wrote:
What is the reason for using pointers (alias pointerOf(T) = T*
etc...)
it works without ! what am i missing ?
What and how exactly works without?
My original solution remembers in the constructor addresses of
variables to fill, then does the filling in opAssign operator,
so I needed a way to store the references and used pointers for
that.
yes, but you are using ref : "auto let(Ts...)(ref Ts vars)"
so vars are changed, no need to store anything, no?
i was wondering if there is some subtleties or efficiency reasons
for using pointers
this work fine with your unittest :
auto let(Ts...)(ref Ts vars) {
struct Let
{
void opAssign( Tuple!Ts xs ) {
foreach(i, t; Ts)
vars[i] = xs[i];
}
static if (sameTypes!Ts) {
import std.conv : text;
void opAssign(Ts[0][] xs) { // redundant but more
effective
enforce(xs.length == Ts.length, "let (...) = ...:
array must have " ~ Ts.length.text ~ " elements.");
foreach(i, t; Ts)
vars[i] = xs[i];
}
void opAssign(R)(R xs) if (isInputRange!R &&
is(ElementType!R == Ts[0])) {
static if (hasLength!R) {
enforce(xs.length >= Ts.length, "let (...) =
...: range must have at least " ~ Ts.length.text ~ " elements.");
}
foreach(i, t; Ts) {
enforce(!xs.empty, "let (...) = ...: range
must have at least " ~ Ts.length.text ~ " elements.");
vars[i] = xs.front;
xs.popFront();
}
}
void opIndexAssign(R)(R xs) if (isInputRange!R &&
is(ElementType!R == Ts[0])) {
foreach(i, t; Ts) {
if(xs.empty) return;
vars[i] = xs.front;
xs.popFront();
}
}
}
}
return Let();
}
Re: let (x,y) = ...
On Sunday, 22 November 2015 at 18:47:34 UTC, visitor wrote: What is the reason for using pointers (alias pointerOf(T) = T* etc...) it works without ! what am i missing ? What and how exactly works without? My original solution remembers in the constructor addresses of variables to fill, then does the filling in opAssign operator, so I needed a way to store the references and used pointers for that.
Re: Release D 2.069.0
On Thursday, 5 November 2015 at 01:08:42 UTC, Martin Nowak wrote: On Wednesday, 4 November 2015 at 17:52:23 UTC, Dmitry Olshansky wrote: If host machine is x64 bit windows try setting large address aware bit on the executable (there are tools to do that IRC), would allow it to eat up to ~4 gigs. We're already doing that since quite a while. https://github.com/D-Programming-Language/dmd/commit/172b55d22bd4a144d889c3fa8d9279d8e0a0ce1c Martin, it seems this is not working. I just had to use editbin manually on my laptop, again.
Re: let (x,y) = ...
On Friday, 20 February 2015 at 09:12:26 UTC, Jacob Carlborg wrote:
On 2015-02-19 05:38, thedeemon wrote:
Creating tuples and returning them from functions is trivial
in D:
auto getTuple() { return tuple("Bob", 42); }
but using them afterwards can be confusing and error prone
auto t = getTuple();
writeln("name is ", t[0], " age is ", t[1]);
I really missed the ML syntax to write
let (name, age) = getTuple();
Didn't someone create a pull request for something like:
auto(name, age) = getTuple();
Or was it a DIP?
Waw! auto(name, age) = getTuple(); looks better :)
Re: The D Language Foundation has $5000 to its name
On Monday, 23 November 2015 at 04:37:18 UTC, Dicebot wrote: And how about GPG signing of releases which comes free and actually helps? :P When you hover over any of the download links on http://dlang.org/download.html, a corresponding .sig link will appear. Is this not what you're referring to?
Re: The D Language Foundation has $5000 to its name
On 2015-11-22 22:45, Brad Anderson wrote: Apple isn't as important because I don't believe it does the Untrusted Developer warning for opening .dmg files nor does it do it for running command line applications. It does for installers. -- /Jacob Carlborg
