Re: Mobile is the new PC and AArch64 is the new x64
On Saturday, 15 September 2018 at 15:25:55 UTC, Joakim wrote: You've probably heard of the possibly apocryphal story of how Blackberry and Nokia engineers disassembled the first iPhone and dismissed it because it only got a day of battery life, while their devices lasted much longer. They thought the mainstream market would care about such battery life as much as their early adopters, but they were wrong. It they'd ask me they would have known. I was a very late adopter of mobile phone and got my first phone in 2000. It was the used Siemens E10D of my brother. It had maximum 1 day of battery life. Then I got at work an Alcatel then a Nokia with ludicrously long battery life, nearly 2 weeks. Result -> my Siemens was always charged properly and I was always reachable. With the others, they were always crapping out on me at the most inapropriate times. With the short battery life, you would never forget to put it on charge. With the long battery life, you would always wait till it's too late.
DCD 0.9.13 and D-Scanner 0.5.11
See detailed changelog and pre-compiled binaries: https://github.com/dlang-community/DCD/releases/tag/v0.9.13 https://github.com/dlang-community/D-Scanner/releases/tag/v0.5.11 DCD update highly recommended if you're still on v0.9.11 or older.
Is it possible to translate this API's C headers?
There is a project that I wish to use from D (https://ultralig.ht). It's Electron, but with forked WebKit and the samples are very, very fast. This is a great compromise between wanting to have a very custom interface and not wanting to use the slow Electron/Sciter/Awesomium/WebView. I am having trouble porting the C headers though. Firstly, I barely know C at all, especially not enough to do this. The extent of my C knowledge is terminal TicTacToe game I made three years ago. I tried using all of the conversion tools under the "Interfacing with C" page of the wiki, but I'm getting import errors. Probably because the paths are all using "<>", expecting an include path from the compiler. I tried to solve this by refractoring the imports to use relative quoted paths. But even when I fixed that, I kept hitting miscellaneous problems with MSVC, LLVM, and every other dependency under the sun those conversion tools needed. So I figured that Windows was just a crappy ecosystem, and tried it on Linux. No easier. So now I'm here, a C noob, really wanting to use Adam's great project from the D language. The only barrier is my lack of knowledge in C. And I definitely do not have the means to port these headers by hand. Could one of you give me pointers about how to go about this? I have the dynamic link libraries, the static libraries, and the header includes. https://github.com/ultralight-ux/ultralight https://github.com/ultralight-ux/ultralight-0.9-api
Re: DMD32 compiling gtkd out of memory on 32bit Windows 7 machine
On Friday, 14 September 2018 at 17:34:59 UTC, Mike Wey wrote: You will also have to pass `--build=plain` to dub because of a optlink bug. https://issues.dlang.org/show_bug.cgi?id=15418 thanks Mike, I tried using `--build-plain`, optlink didn't report out of memory, but it hangs ! ``` Compiling source\utils.d... Linking... OPTLINK (R) for Win32 Release 8.00.17 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html OPTLINK : Warning 9: Unknown Option : LLIB OPTLINK : Warning 9: Unknown Option : WIN32 C:\Users\Administrator.USER-20180912OL\AppData\Local\dub\packages\gtk-d-3.8.3\gtk-d\.dub\build\library-plain-windows-x86-dmd_2082-BF70B0A83AEE3E77C0F6B230586D03B2\gtkd-3.lib Warning 178: .LIB pagesize exceeds 512 ``` my building command is ` dub build --compiler=dmd -a=x86 -c=windows --build-mode=singleFile --build=plain --force` Thanks !
Re: DIP 1015--removal of integer & character literal conversion to bool--Final Review
On Sunday, 16 September 2018 at 23:59:18 UTC, aliak wrote:
What about:
enum E: bool {
no, yes
}
void main() {
E e = cast(E)(0);
}
Would be illegal I assume?
You have an explicit cast, so no, it would be fine.
Re: Mobile is the new PC and AArch64 is the new x64
On Sunday, 16 September 2018 at 15:11:42 UTC, Joakim wrote: On Sunday, 16 September 2018 at 10:25:30 UTC, Dave Jones wrote: Some analysts have predicted that PC sales will plateau at some point and if that's where we're at now then 30% drop in shipments is not death of the market. I see no reason why they would plateau, looks like wishful thinking to me. Might be, but so is trying to convince everyone your predictions are correct so they will focus their work on the issues important to you. I think a large part of it is that PCs got fast enough for most people about 7-10 years ago. So it was a combination of mobile, and people no longer needing to get newer faster machines. The upgrade cycle moved from "I need a newer faster computer" to "I'll wait till my current system is worn out". (For a lot of people anyway) Sure, that's part of it, but that suggests that once smartphones reach that performance threshold, they will replace PCs altogether. I think we've reached that threshold now. If it was just about performance, but it's not. And just because there's been a trend for 5 or 6 years doesnt mean it will continue so inevitably. Sure, but these trends almost never reverse. ;) It doesnt need to reverse for "the PC is dead" to be false. Plateaus almost never happen, it's not the natural order of things. OK the market stabilises. Because for about £300 you can get an intel NUC system with 120GB SSD, which is more powerful and more upgradeable than your £700 mobile device. And some people still want that. And because most people have more than one TV, some have multiple phones, phones and tablets, and desktops, and multiple games consoles. And they still use them all in different situations. That's more on the high end, where people use many devices. On the low- to mid-end of the market, where most of the sales happen, people are happy to buy fewer devices that get the job done. Most households have more devices than ever before, and hardware is only getting cheaper. The idea that people will have to choose just one device is plainly wrong. I find it strange that you think the PC won't also be rolled up by mobile like this. Can you put a 3GB hard drive in your phone? Or a high end graphics card? Or a soundcard with balanced outputs? Yes you can bring up examples of people who made mistakes predicting the future but that works both ways. You're just as guilty of seeing a two points and drawing a straight line though them. Except none of these examples or my own prediction are based on simple extrapolation between data points. Rather, we're analyzing the underlying technical details and capabilities and coming to different conclusions about whether the status quo is likely to remain. So I don't think any of us are "guilty" of your charge. Of course you are, you're making predictions and assuming the trends will continue, you assume the technical details are all important. Im saying they are only part of it, that people have requirements / preferences outside of how powerful the device is. Lots of people were predicting ebooks would kill the real book market a few years back, turns out people still prefer to have an actual paper book to read, ebooks peaked a few years ago and real books have been in growth ever since. That was people seeing a trend and assuming it would continue just like you are. No, print is pretty much dead, it's just hard to track because so many ebooks have gone indie now: https://www.geekwire.com/2018/traditional-publishers-ebook-sales-drop-indie-authors-amazon-take-off/ What are these magical "requirements/preferences" that you cannot name, that you believe will keep print alive? That will be really funny. :) You obviously didn't research thoroughly enough, the site that was the source for the geekwire article shows quite clearly that print books still outsell ebooks almost twice over. http://authorearnings.com/wp-content/uploads/2017/01/Slide29.jpg and yes that's with indie published books included. Another interesting thing from that report was the average price of indie ebooks was $2.95 http://authorearnings.com/wp-content/uploads/2017/01/Slide26.jpg So even selling ebooks for peanuts cant catch them up.
Re: DIP 1015--removal of integer & character literal conversion to bool--Final Review
On Sunday, 16 September 2018 at 01:29:38 UTC, Mike Franklin wrote:
On Saturday, 15 September 2018 at 20:07:06 UTC, Steven
Schveighoffer wrote:
Looks pretty good to me. The only question I have is on this
part:
enum YesNo : bool { no, yes } // Existing implementation: OK
// After stage 1: Deprecation
warning
// After stage 2: Error
// Remedy: `enum YesNo : bool {
no = false, yes = true }`
Why is this necessary? I can't see how there are integer
literals being used here, or how implicitly going from `false`
to `true` in the 2 items being enumerated is going to be
confusing.
You're right, I just tested the implementation, and this is not
necessary. I'll remove it. Thanks!
Mike
What about:
enum E: bool {
no, yes
}
void main() {
E e = cast(E)(0);
}
Would be illegal I assume?
And I think the confusing part about "enum E: bool { yes, no }"
is that most people did not catch the bug in the code I just
wrote in this sentence.
Cheers,
- Ali
Re: A facebook group for D programmers
On 9/16/18 2:51 PM, Peter Alexander wrote: On Sunday, 16 September 2018 at 20:19:32 UTC, Murilo wrote: Hello everyone, I was so amazed with the D language that I created a facebook group for us all to be connected and share information. It is called "Programming in D", it has already 55 members. Please join the group and invite everyone else to join it. That way we can show the world how amazing the D language is. Probably would be a good idea to link to the group. I couldn't find it with search. This seems pretty... spamish. Apologies if that's not true, but the original message is so fill-in-the-blank-with-target-topic that it's hard to take seriously. Also the "Already has 55 members" seems weird too. Especially if it's never been announced before. -Steve
Re: int/longRe: DIP 1015--removal of integer & character literal conversion to bool--Final Review
On Sunday, 16 September 2018 at 17:33:27 UTC, Steven Schveighoffer wrote: As precedent, we do have -transition=intpromote, which disables the requirement for casting smaller integers to int first. And -dip1000. Maybe it would be nice to have a generic -future=[changeid] flag. I'd like it if these features could be implemented orthogonally enough that we could opt in on a per-module basis and have the same compiler compatible with a much wider range of code. That would be a fair bit of work. Hm... another option is to have a switch identify "useless" casts once the deprecation period is over. Or add it into dfix. Adding it to dfix would be nice, but dfix isn't official or distributed with dmd by default. Also, dfix uses libdparse internally, which is insufficient for handling this type of analysis. libdparse parses code, but this requires figuring out which overloads would be called.
Re: phobo's std.file is completely broke!
To elaborate: On Sunday, 16 September 2018 at 22:40:45 UTC, Vladimir Panteleev wrote: If *YOU* are OK with the consequences of complexity, implement this in YOUR code, but do not enforce it upon others. This is much better done in user code anyway, because you only need to expand / normalize the path and prepend the prefix only once (root of the directory tree you're operating on), instead of once per directory call. We could add a `string longPath(string)` function in Phobos (no-op on POSIX, expands and prepends prefix on Windows). I believe I suggested the same in the bug report years ago when we discussed it. It is absolutely not acceptable behavior. Complain to Microsoft. The OS should not allow users to create or select paths that programs cannot operate on without jumping through crazy hoops. Microsoft could have solved this easily enough: extern(System) void AllowLongPaths(); Programs (or programming language runtimes) which can handle paths longer than MAX_PATH could call that function. It can also be used as a hint to the OS that file/directory selection dialogs, as you mentioned, are allowed to select paths longer than MAX_PATH.
Re: phobo's std.file is completely broke!
On Sunday, 16 September 2018 at 16:17:21 UTC, tide wrote: Nothing is "locked behind management". If you feel that some issue important to you is stalled, you can create a forum thread, or email Walter/Andrei to ask for a resolution. Funny the other guy was saying to create a bugzilla issue. Do that *first*. The path needs to be normalized, which means that \.\ and \..\ fragments need to be removed away first. Depending on your interpretation of symlinks/junctions/etc., "foo/bar/../" might mean something else than "foo/" if "bar" is a reparse point. All these issues yet for some reason this function was included in the lot: https://dlang.org/phobos/std_path.html#absolutePath [...] This issue exists anyways, you'd only expand the path when it need to be used. If the file changes within milliseconds, I don't see that happening often and if it does there's a flaw in your design that'd happen even if the path didn't have to be constructed first. You've missed the point. Complexity breeds bugs and unexpected behavior. The expectation is that D's function to delete a file should do little else than call the OS function. If *YOU* are OK with the consequences of complexity, implement this in YOUR code, but do not enforce it upon others. So you pass a valid path (selected by a user through a UI) to rmDir, and it doesn't remove the directory. You think this is acceptable behavior? It is absolutely not acceptable behavior. Complain to Microsoft. The OS should not allow users to create or select paths that programs cannot operate on without jumping through crazy hoops.
Re: Mobile is the new PC and AArch64 is the new x64
On 9/12/2018 11:38 AM, Joakim wrote:> On Wednesday, 12 September 2018 at 06:41:38 UTC, Gambler wrote: >> On 9/10/2018 9:43 AM, Joakim wrote: >>> Yes, I know, these devices won't replace your quad-core Xeon >>> workstation with 32-64 GBs of RAM anytime soon, but most people don't >>> need anywhere near that level of compute. That's why PC sales keep >>> dropping while mobile sales are now 6-7X that per year: >> I'm all for supporting modern open CPU architectures. At the same time, >> I fear that the specific trend you're describing here (people ditching >> PCs for cellphones/tablets) is effectively a reversal of the PC >> revolution. >> >> For the last 30+ years people benefited from "trickle down computing". >> They had access to PCs that were equivalent to cutting edge servers of >> 6-7 years prior. They had ability to choose their operating system, >> expand and upgrade their hardware and install any software they wanted. >> >> All of this is breaking down right now. > > Yes and no, it is true that that is the way tech _used_ to diffuse. > However, do you know what the largest tech company in the world is right > now? It's not IBM, Apple, HP, or Microsoft, ie none of the server or PC > companies. It's Apple, which doesn't sell into the server or traditional > enterprise markets almost at all and only has 15-20% unit share in the > mobile market. > > In other words, consumer tech markets are _much_ larger than the > server/enterprise markets that used to lead tech R, which means > consumer tech like mobile is what leads the way now. > > As for choosing your own OS, that's still possible, but as always, it > can be tough to get drivers for your hardware: > > https://together.jolla.com/question/136143/wiki-available-devices-running-sailfish-os/ > > > And if you simply want to tinker with the Android OS on your device, > there are many ways to do that: > > https://www.xda-developers.com/how-to-install-custom-rom-android/ > > No need to expand and upgrade your hardware when prices keep dropping in > this Darwinian market. There's now a $500 phone with a faster chip than > the one I got just 7 months back for $700: > > https://m.newegg.com/products/N82E16875220078 > > As for installing any software you want, Android allows it: it's how I > debug the apps I build on my phone or tablet. The iPhone doesn't, but > it's a minority of the mobile market. > >> Intel got lazy without competition and high-end CPU architectures >> stagnated. All the cutting-edge computing is done on NVidia cards >> today. It requires hundreds of gigabytes of RAM, tens of terabytes of >> data and usage of specialized computing libraries. I very much doubt >> this will "trickle down" to mobile in foreseeable future. Heck, most >> developer laptops today have no CUDA capabilities to speak of. > > I question the need for such "cutting-edge computing" in the first > place, but regardless, it has already moved down to mobile and other > edge devices: > > https://arstechnica.com/gadgets/2017/10/the-pixel-2-contains-a-custom-google-soc-the-pixel-visual-core/ > > https://www.theverge.com/2018/7/26/17616140/google-edge-tpu-on-device-ai-machine-learning-devkit > > >> Moreover, mobile devices are locked down by default and it's no >> trivial task to break out of those walled gardens. IIRC, Apple has an >> official policy of not allowing programming tools in their app store. >> Alan Kay had to personally petition Steve Jobs to allow Scratch to be >> distributed, so kids could learn programming. I believe the general >> policy is still in place. > > They have their own app for that now: > > https://www.apple.com/swift/playgrounds/ > >> Android is better, but it's still a horror to do real work on, >> compared to any PC OS. Fine, you rooted it, installed some compilers >> and so on. How will you share your software with fellow Android users? > > You seem to have missed all the posts I've made here before about native > Android support for ldc: :) _I have never rooted any of my Android > devices_. Compiling D code on most any Android device is as simple as > installing an app from the official Play Store and typing a single > command, `apt install ldc`: > > https://wiki.dlang.org/Build_D_for_Android > > The instructions there even show you how to package up an Android GUI > app, an apk, on Android itself, by using some other packages available > in that Android app. > >> In essence, we are seeing the rapid widening of two digital divides. >> The first one is between users and average developers. The second one >> is between average developers and researchers at companies like >> Google. I very much doubt that we will see an equivalent of today's >> high-end machine learning server on user's desk, let alone in anyone's >> pocket, within 7 years. > > I disagree on both counts. First off, people were running supercomputers > and UNIX workstations while you were piddling along on your PC decades > ago. That changed nothing about what you were able to
Re: A facebook group for D programmers
On Sunday, 16 September 2018 at 20:19:32 UTC, Murilo wrote: Hello everyone, I was so amazed with the D language that I created a facebook group for us all to be connected and share information. It is called "Programming in D", it has already 55 members. Please join the group and invite everyone else to join it. That way we can show the world how amazing the D language is. Probably would be a good idea to link to the group. I couldn't find it with search.
A facebook group for D programmers
Hello everyone, I was so amazed with the D language that I created a facebook group for us all to be connected and share information. It is called "Programming in D", it has already 55 members. Please join the group and invite everyone else to join it. That way we can show the world how amazing the D language is.
Re: More fun with autodecoding
On 09/15/2018 04:29 PM, Jonathan M Davis wrote:
Adding any sort of Concepts feature to D
would be very much at odds with DbI.
I'm not very familiar with C++'s attempted approaches to concepts, so
maybe we're thinking of two different things by "concepts", but I don't
see why it would be at odds with DbI. If anything, they would seem to
compliment each other well, each one filling in where the other hits its
limit. Even just a simple example:
void foo(ForwardRange r1, InputRange r2)
if(hasLength!r1)
{...}
Andrei is right that a no-DbI version of that would suck: Hierarchies
are no good for a series of orthogonal options. But at the same time,
the equivalent current-D code would comparatively be a mess, too.
Although...and maybe I'm just typing out of my &%@ here, maybe some kind
of templated concept:
void foo(ForwardRange!WithLength r1, InputRange r2)
{...}
Overall though, I don't think that there's really any disagreement that it
would be very desirable to get the compiler to provide better information
about which parts of a template constraint are true and which are false. The
problem is really that someone needs to come up with a scheme to do so that
will work reasonably well and then implement it, and no on has done that
yet.
Agreed, but let's be realistic, this *is* D: How many years has it been
since assertPred was rejected in favor of the improved-assert-messages
vaporware? It's hard to have much faith in such a thing happening here
either. (Not that I'm under any illusion that concept-like stuff would
be any more likely.)
Though, I'd be glad to be proven wrong either way.
-- Danny Downer
[Issue 15512] extern(C++, ns) should consider taking a string
https://issues.dlang.org/show_bug.cgi?id=15512 Manu changed: What|Removed |Added Keywords||C++ --
[Issue 18906] Template specialisations should not be stripped if they're not called
https://issues.dlang.org/show_bug.cgi?id=18906 Manu changed: What|Removed |Added Keywords||C++, industry Severity|normal |major --- Comment #3 from Manu --- This is actually pretty problematic issue... --
[Issue 18999] MSCRT selection specifies _ITERATOR_DEBUG_LEVEL and produces a `version`
https://issues.dlang.org/show_bug.cgi?id=18999 Manu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Manu --- This is being addressed by other issues. --
Re: Bug in VD
This works for me with dmd 2.081 for -m64 and -m32mscoff
void foo()
{
string[] x = ["1"];
foreach(string a; x) {
auto b = a;
}
string[] y = ["2"];
foreach(string a; y) {
auto b = a;
}
}
Please show a full example and add some details about your environment
(e.g. compiler version, VS version, target architecture).
On 15/09/2018 00:25, Josphe Brigmo wrote:
When having two loops it seems the variables are never show if the name
is already used:
foreach(string a; x) { // a not shown in the locals or autos}
foreach(string a; y) { // a not shown }
renaming one of them to b, say, works as long as be wasn't used
somewhere else.
Re: Fast linear search for non-null key in slice of Nullable(T, T.max)
On Sunday, 16 September 2018 at 16:50:32 UTC, Neia Neutuladh wrote: On Sunday, 16 September 2018 at 16:28:20 UTC, Per Nordlöw wrote: If I have alias N = Nullable!(T, T nullValue) fed as template parameter to another template how can I at compile-time get the `nullValue` ? import std.traits; enum nullValue = TemplateArgsOf!(N)[1]; Thanks. However, I just realized that I need to cast the array of nullables to an array of underlying unnulled types and search that array using an unnulled key. So I have no use for the nullValue, anyway.
[Issue 18851] std.net.curl.post cannot be used with !ubyte
https://issues.dlang.org/show_bug.cgi?id=18851 wolframw changed: What|Removed |Added CC||wolfr...@protonmail.com Assignee|nob...@puremagic.com|wolfr...@protonmail.com --
Re: extern(C++, ns) is wrong
On 9/14/18 6:41 PM, Neia Neutuladh wrote: Specifically, Walter wants this to compile: module whatever; extern(C++, foo) void doStuff(); extern(C++, bar) void doStuff(); And he's not too concerned that you might have to use doubly fully qualified names to refer to C++ symbols, like: import core.stdcpp.sstream; import core.stdcpp.vector; core.stdcpp.vector.std.vector v; This is probably the best explanation of why the current situation sucks. -Steve
Re: int/longRe: DIP 1015--removal of integer & character literal conversion to bool--Final Review
On 9/15/18 8:36 PM, Nicholas Wilson wrote: Without it, I get a (possibly quite a lot of) deprecation warnings and I have to insert a cast to the corresponding type, e.g. f(cast(int)E.a)/g(cast(long)(a - b)), to verify the behaviour under the new system and silence the deprecation warning (absolutely necessary if using `-de`). Then I have to delete them after stage 2, but what if I want to support older compilers? Well then I have to wait until they are sufficiently old enough. As precedent, we do have -transition=intpromote, which disables the requirement for casting smaller integers to int first. So the way I would expect someone to migrate their project: 1. Examine all deprecations, looking for ones where I actually *WANT* the bool version to be called. Insert cast there. 2. Enable the -transition=nobooldemote or whatever we call it. 3. Once the deprecation period is over, remove the -transition switch. If I wanted a version to be compilable with older versions of dmd, then I would have to cast. Hm... another option is to have a switch identify "useless" casts once the deprecation period is over. Or add it into dfix. -Steve
Re: Fast linear search for non-null key in slice of Nullable(T, T.max)
On Sunday, 16 September 2018 at 16:28:20 UTC, Per Nordlöw wrote: If I have alias N = Nullable!(T, T nullValue) fed as template parameter to another template how can I at compile-time get the `nullValue` ? import std.traits; enum nullValue = TemplateArgsOf!(N)[1];
Re: Cannot use UFCS in lambda?
On Sunday, 16 September 2018 at 10:55:43 UTC, berni wrote: The problem is more general: you can only use top-level symbols in UFCS. You can use an identity alias template to bypass this: https://blog.thecybershadow.net/2015/04/28/the-amazing-template-that-does-nothing/ (search for UFCS in the page). Good to know. :-) Worth noting, this is now included in Phobos as `std.meta.Alias`.
Re: phobo's std.file is completely broke!
On Sunday, 16 September 2018 at 03:19:12 UTC, Vladimir Panteleev wrote: On Sunday, 16 September 2018 at 02:58:30 UTC, tide wrote: There are a lot of issues that aren't simple bugs that just anyone can fix. They are issues that are locked behind management. One's that are 4 years old for example, they are probably some bug locked behind management. That's why they get so old. From the comments it is not clear that a pull request wouldn't be accepted to fix the issue. Personally I think phobos should not exception for long file names. Nothing is "locked behind management". If you feel that some issue important to you is stalled, you can create a forum thread, or email Walter/Andrei to ask for a resolution. Walters concern is that the path will change unexpected for the user. Where does that matter for something like rmDir ? The user passes a long path, and rmDir swallows it, never to be seen again by the user. What does it matter if the path gets corrected if it is too long? It's more than that. The path needs to be normalized, which means that \.\ and \..\ fragments need to be removed away first. Depending on your interpretation of symlinks/junctions/etc., "foo/bar/../" might mean something else than "foo/" if "bar" is a reparse point. The path also needs to be absolute, so it has to be expanded to a full path before it can be prefixed with the UNC prefix. Given how the current directory is state tied to the process (not thread), you get bonus race condition issues. There's also issues like the current directory object being renamed/moved; then a relative path will no longer correspond to what the program thinks the absolute paths is. All things considered, this goes well into the territory of "not D's problem". My personal recommendation: if you care about long path names, use an operating system which implements them right. Well my mistake, seems absolutePath is just named incorrectly and should be more accurately named concatenatePath.
Fast linear search for non-null key in slice of Nullable(T, T.max)
If I have alias N = Nullable!(T, T nullValue) fed as template parameter to another template how can I at compile-time get the `nullValue` ? I need this to implement fast linear search over a slice of type Nullable!(ulong, ulong.max)[] searching for a non-null key without needing to call a combination of Nullable's `isNull` and `get` inside the loop. Which is significantly slower than knowing the non-null value to search for. Which also can be implemented using sentinel-based search. In my case it would have been convenient to have public access to Nullable!(T, T nullValue)._value I need this in a hash table of mine that uses open addressing that makes use of Nullable to indicate empty slot.
Re: phobo's std.file is completely broke!
On Sunday, 16 September 2018 at 03:19:12 UTC, Vladimir Panteleev wrote: On Sunday, 16 September 2018 at 02:58:30 UTC, tide wrote: There are a lot of issues that aren't simple bugs that just anyone can fix. They are issues that are locked behind management. One's that are 4 years old for example, they are probably some bug locked behind management. That's why they get so old. From the comments it is not clear that a pull request wouldn't be accepted to fix the issue. Personally I think phobos should not exception for long file names. Nothing is "locked behind management". If you feel that some issue important to you is stalled, you can create a forum thread, or email Walter/Andrei to ask for a resolution. Walters concern is that the path will change unexpected for the user. Where does that matter for something like rmDir ? The user passes a long path, and rmDir swallows it, never to be seen again by the user. What does it matter if the path gets corrected if it is too long? It's more than that. The path needs to be normalized, which means that \.\ and \..\ fragments need to be removed away first. Depending on your interpretation of symlinks/junctions/etc., "foo/bar/../" might mean something else than "foo/" if "bar" is a reparse point. The path also needs to be absolute, so it has to be expanded to a full path before it can be prefixed with the UNC prefix. Given how the current directory is state tied to the process (not thread), you get bonus race condition issues. There's also issues like the current directory object being renamed/moved; then a relative path will no longer correspond to what the program thinks the absolute paths is. All things considered, this goes well into the territory of "not D's problem". My personal recommendation: if you care about long path names, use an operating system which implements them right. I'd agree with you that it isn't **Phobos** problem, but since most of the functions there aren't @system nor @nogc, I do believe it is. And if you want @system and @nogc with no safety you can go look into core.stdc for that.
Re: phobo's std.file is completely broke!
On Sunday, 16 September 2018 at 03:19:12 UTC, Vladimir Panteleev wrote: On Sunday, 16 September 2018 at 02:58:30 UTC, tide wrote: There are a lot of issues that aren't simple bugs that just anyone can fix. They are issues that are locked behind management. One's that are 4 years old for example, they are probably some bug locked behind management. That's why they get so old. From the comments it is not clear that a pull request wouldn't be accepted to fix the issue. Personally I think phobos should not exception for long file names. Nothing is "locked behind management". If you feel that some issue important to you is stalled, you can create a forum thread, or email Walter/Andrei to ask for a resolution. Funny the other guy was saying to create a bugzilla issue. Walters concern is that the path will change unexpected for the user. Where does that matter for something like rmDir ? The user passes a long path, and rmDir swallows it, never to be seen again by the user. What does it matter if the path gets corrected if it is too long? It's more than that. The path needs to be normalized, which means that \.\ and \..\ fragments need to be removed away first. Depending on your interpretation of symlinks/junctions/etc., "foo/bar/../" might mean something else than "foo/" if "bar" is a reparse point. All these issues yet for some reason this function was included in the lot: https://dlang.org/phobos/std_path.html#absolutePath The path also needs to be absolute, so it has to be expanded to a full path before it can be prefixed with the UNC prefix. Given how the current directory is state tied to the process (not thread), you get bonus race condition issues. There's also issues like the current directory object being renamed/moved; then a relative path will no longer correspond to what the program thinks the absolute paths is. This issue exists anyways, you'd only expand the path when it need to be used. If the file changes within milliseconds, I don't see that happening often and if it does there's a flaw in your design that'd happen even if the path didn't have to be constructed first. All things considered, this goes well into the territory of "not D's problem". My personal recommendation: if you care about long path names, use an operating system which implements them right. So you pass a valid path (selected by a user through a UI) to rmDir, and it doesn't remove the directory. You think this is acceptable behavior?
Re: Mobile is the new PC and AArch64 is the new x64
On Sunday, 16 September 2018 at 15:56:25 UTC, Neia Neutuladh wrote: Better network connectivity and cloud-based gaming would erode another segment of powerful personal computers. I wish companies actually cared for providing better networks. But the truth is they are fine charging for their overpriced internet packages as it stands. They don't get anything out of providing better internet for cheaper. The output of throughput you would need for something like 4k gaming or 144hz. I don't ever see (at least america's) internet structure supporting that in 30 years.
Re: Mobile is the new PC and AArch64 is the new x64
On Sunday, 16 September 2018 at 10:25:30 UTC, Dave Jones wrote: Because for about £300 you can get an intel NUC system with 120GB SSD, which is more powerful and more upgradeable than your £700 mobile device. And some people still want that. For the typical person, it's more likely that they'll get a laptop and replace the whole thing at once instead of upgrading. And a new rise of convergence devices would reduce laptop ownership. Better network connectivity and cloud-based gaming would erode another segment of powerful personal computers. That could also impact things like content editing -- Adobe Creative Cloud might actually be entirely cloud-based eventually. Which is a mild improvement in that you wouldn't need a good computer to run Premiere Pro, but a large problem for actually being able to access your data and products you've purchased. It angers both the EFF and digital archivists. Anyway, it's at least moderately plausible that, thirty years from now, desktop computers will be considered specialized gear.
Re: Mobile is the new PC and AArch64 is the new x64
That is, it is not just the performance that affects the sales of phones. There's a lot of factors that lead to there being new phones sales. Know someone that's gone through 3 phones in comparison to just the one I have. Treadmills eat phones for breakfast.
Re: Mobile is the new PC and AArch64 is the new x64
On Sunday, 16 September 2018 at 15:11:42 UTC, Joakim wrote: I say that almost 30% drop in PC sales over the last 7 years is mostly due to the rise of mobile. I think a large part of it is that PCs got fast enough for most people about 7-10 years ago. So it was a combination of mobile, and people no longer needing to get newer faster machines. The upgrade cycle moved from "I need a newer faster computer" to "I'll wait till my current system is worn out". (For a lot of people anyway) Sure, that's part of it, but that suggests that once smartphones reach that performance threshold, they will replace PCs altogether. I think we've reached that threshold now. I feel only looking at sales stats is irrelevant. I know people that have lost their phone and just bought a new phone. They get stolen a lot more easily. If your screen breaks you are better off buying a new phone as the cost of replacing the screen is going to be almost as much as a new one. Someone I know had to fight his boss to repair his phone cause he didn't want a brand new iPhone, he still has an Android device and they switched to Apple a while back. Note, it still costed more to buy the new phone than repair his old one. Computers last much longer, I've had the one I have right now for 8 years. It runs everything I need it to. Faster than a smartphone or tablet, or even most newer laptops still. There's no reason to buy a new one, not that I would buy a prebuilt one anyways. Which I'm pretty sure are what those sales represent. Can't really count a CPU sale as a "PC" sale as it might just be someone upgrading from their old PC.
Re: Mobile is the new PC and AArch64 is the new x64
On Sunday, 16 September 2018 at 10:25:30 UTC, Dave Jones wrote: On Sunday, 16 September 2018 at 04:47:11 UTC, Joakim wrote: On Sunday, 16 September 2018 at 01:03:27 UTC, Dave Jones wrote: I know a lot of people who did, which explains the 28% drop in PC sales since they peaked in 2011, the year after the iPad came out. Many of those people who used to buy PCs have switched to tablets and other mobile devices. Yet PC sales are up this year, mobile is down, and tablet sales have fallen for 3 years in a row. Eh, these are all mostly mature markets now, so slight quarterly dips or gains don't matter much anymore. What does it matter that PC sales were up 2-3% last quarter when 7 times as many smartphones and mobile devices were sold in that same quarter? Some analysts have predicted that PC sales will plateau at some point and if that's where we're at now then 30% drop in shipments is not death of the market. I see no reason why they would plateau, looks like wishful thinking to me. I say that almost 30% drop in PC sales over the last 7 years is mostly due to the rise of mobile. I think a large part of it is that PCs got fast enough for most people about 7-10 years ago. So it was a combination of mobile, and people no longer needing to get newer faster machines. The upgrade cycle moved from "I need a newer faster computer" to "I'll wait till my current system is worn out". (For a lot of people anyway) Sure, that's part of it, but that suggests that once smartphones reach that performance threshold, they will replace PCs altogether. I think we've reached that threshold now. And just because there's been a trend for 5 or 6 years doesnt mean it will continue so inevitably. Sure, but these trends almost never reverse. ;) It doesnt need to reverse for "the PC is dead" to be false. Plateaus almost never happen, it's not the natural order of things. For example, newspapers hoped their ad revenue had plateaued from 2000-2005, then they plunged: https://en.m.wikipedia.org/wiki/File:Naa_newspaper_ad_revenue.svg I've predicted that a similar plunge is about to happen to PC sales. I actually think most people would prefer a separate desktop and mobile device, whether that desktop is just the size of pack of cigarettes, or a big box with 5 fans in it. Why? Given how price-sensitive the vast majority of the computing-buying public is- that excludes the Apple sheeple who actually seem to get a hard-on from rising iPhone prices, all the better for them to show how much money they've lucked into by brandishing their "gold" iPhone ;) - I don't see most willing to spend twice on two devices, that could be replaced by just one. Until recently, they didn't have a choice, as you couldn't use your mobile device as a desktop, but the just-released devices I linked in the first post in this thread are starting to change that. Because for about £300 you can get an intel NUC system with 120GB SSD, which is more powerful and more upgradeable than your £700 mobile device. And some people still want that. And because most people have more than one TV, some have multiple phones, phones and tablets, and desktops, and multiple games consoles. And they still use them all in different situations. That's more on the high end, where people use many devices. On the low- to mid-end of the market, where most of the sales happen, people are happy to buy fewer devices that get the job done. This "one device" thing is your preference and you're projecting it onto everyone else. Looks to me like you're the one projecting here. People used to buy standalone mp3 players, GPS devices, point-and-shoot cameras, handheld gaming consoles, etc., etc. Sales of all those standalone devices have been devastated by the smartphone; here's just one example of what happened to camera sales after the smartphone took over, which I've linked on this forum before: https://petapixel.com/2017/03/03/latest-camera-sales-chart-reveals-death-compact-camera/ I find it strange that you think the PC won't also be rolled up by mobile like this. Yes you can bring up examples of people who made mistakes predicting the future but that works both ways. You're just as guilty of seeing a two points and drawing a straight line though them. Except none of these examples or my own prediction are based on simple extrapolation between data points. Rather, we're analyzing the underlying technical details and capabilities and coming to different conclusions about whether the status quo is likely to remain. So I don't think any of us are "guilty" of your charge. Of course you are, you're making predictions and assuming the trends will continue, you assume the technical details are all important. Im saying they are only part of it, that people have requirements / preferences outside of how powerful the device is. Lots of people were predicting ebooks would kill the real book market a
Re: Manual delegates
On Sunday, 16 September 2018 at 14:12:27 UTC, Guillaume Piolat wrote: Anyone has any information about the ABI of delegates? In particular how to call them with a particular "this"/frame pointer? To solve a hairy problem I need a delegate with a synthesized frame pointer. https://dpaste.dzfl.pl/cf44417c98f9 The problem is that delegate forwarding seems to require GC closures. I want manually-managed closures. Have a look at the implementation of toDelegate, which does exactly this: https://github.com/dlang/phobos/blob/v2.082.0/std/functional.d#L1463
Re: Manual delegates
On Sunday, 16 September 2018 at 14:12:27 UTC, Guillaume Piolat wrote: In particular how to call them with a particular "this"/frame pointer? Related thread: https://forum.dlang.org/post/wjbhpztovxratexao...@forum.dlang.org
Manual delegates
Anyone has any information about the ABI of delegates? In particular how to call them with a particular "this"/frame pointer? To solve a hairy problem I need a delegate with a synthesized frame pointer. https://dpaste.dzfl.pl/cf44417c98f9 The problem is that delegate forwarding seems to require GC closures. I want manually-managed closures.
Re: DIP 1015--removal of integer & character literal conversion to bool--Final Review
On 9/15/18 6:29 PM, Mike Franklin wrote:
On Saturday, 15 September 2018 at 20:07:06 UTC, Steven Schveighoffer wrote:
Looks pretty good to me. The only question I have is on this part:
enum YesNo : bool { no, yes } // Existing implementation: OK
// After stage 1: Deprecation warning
// After stage 2: Error
// Remedy: `enum YesNo : bool { no =
false, yes = true }`
Why is this necessary? I can't see how there are integer literals
being used here, or how implicitly going from `false` to `true` in the
2 items being enumerated is going to be confusing.
You're right, I just tested the implementation, and this is not
necessary. I'll remove it. Thanks!
Then I have no objections, looks like a nice positive change to me!
-Steve
Re: try find the fastest way to convert a group string into index?
On Sunday, 16 September 2018 at 11:51:24 UTC, learnfirst1 wrote: On Sunday, 16 September 2018 at 11:30:11 UTC, learnfirst1 wrote: On Sunday, 16 September 2018 at 10:14:24 UTC, Vladimir Panteleev wrote: I will test pcre solution vs mpfc for benchmark. the pcre is easy to deal with low/up case. The PCRE: /^(?:Accept(*:0)|Accept\-Charset(*:1)|Accept\-Encoding(*:2)|Accept\-Language(*:3)|Access\-Control\-Allow\-Credentials(*:4)|Access\-Control\-Allow\-Origin(*:5)|Access\-Control\-Allow\-Methods(*:6)|Access\-Control\-Allow\-Headers(*:7)|Access\-Control\-Max\-Age(*:8)|Access\-Control\-Expose\-Headers(*:9)|Access\-Control\-Request\-Method(*:10)|Access\-Control\-Request\-Headers(*:11)|Age(*:12)|Allow(*:13)|Authorization(*:14)|Cache\-Control(*:15)|Connection(*:16)|Content\-Encoding(*:17)|Content\-Language(*:18)|Content\-Length(*:19)|Content\-Location(*:20)|Content\-Range(*:21)|Content\-Security\-Policy(*:22)|Content\-Type(*:23)|Cookie(*:24)|Date(*:25)|ETag(*:26)|Expect(*:27)|Expires(*:28)|Host(*:29)|If\-Match(*:30)|If\-Modified\-Since(*:31)|If\-None\-Match(*:32)|If\-Range(*:33)|If\-Unmodified\-Since(*:34)|Last\-Modified(*:35)|Location(*:36)|Origin(*:37)|Pragma(*:38)|Proxy\-Authenticate(*:39)|Proxy\-Authorization(*:40)|Range(*:41)|Referer(*:42)|Retry\-After(*:43)|Sec\-Websocket\-Exte! nsions(*:44)|Sec\-Websocket\-Key(*:45)|Sec\-Websocket\-Origin(*:46)|Sec\-Websocket\-Protocol(*:47)|Sec\-Websocket\-Version(*:48)|Server(*:49)|Set\-Cookie(*:50)|Strict\-Transport\-Security(*:51)|Transfer\-Encoding(*:52)|Upgrade(*:53)|User\-Agent(*:54)|Vary(*:55)|Via(*:56)|WWW\-Authenticate(*:57))$/i
[Issue 18957] extern(C++) doesn't mangle 'std' correctly on posix systems
https://issues.dlang.org/show_bug.cgi?id=18957 Илья Ярошенко changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Илья Ярошенко --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/9cb46f842778b3b7d3cb4efe698c32765fd72220 fix Issue 19248 https://github.com/dlang/dmd/commit/2db16adbced9e7736802c3d4fbaa0ca6c79f8dc5 Merge pull request #8700 from 9il/issue19248 [~regression fix] fix Issue 19248 and reopened 18957 merged-on-behalf-of: David Nadlinger --
[Issue 19248] Wrong mangle for C++ const STL classes/structs
https://issues.dlang.org/show_bug.cgi?id=19248 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/9cb46f842778b3b7d3cb4efe698c32765fd72220 fix Issue 19248 https://github.com/dlang/dmd/commit/2db16adbced9e7736802c3d4fbaa0ca6c79f8dc5 Merge pull request #8700 from 9il/issue19248 [~regression fix] fix Issue 19248 and reopened 18957 merged-on-behalf-of: David Nadlinger --
[Issue 19248] Wrong mangle for C++ const STL classes/structs
https://issues.dlang.org/show_bug.cgi?id=19248 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: try find the fastest way to convert a group string into index?
On Sunday, 16 September 2018 at 11:30:11 UTC, learnfirst1 wrote: On Sunday, 16 September 2018 at 10:14:24 UTC, Vladimir Panteleev wrote: It has to be case Case Insensitive, so before I run mpfh for each new request headers, I need to convert the keys into low or up case. this value can be storage on a stack local tmp cache. and I has to run it on the get(string key) method again.
Re: try find the fastest way to convert a group string into index?
On Sunday, 16 September 2018 at 10:14:24 UTC, Vladimir Panteleev
wrote:
On Sunday, 16 September 2018 at 10:04:09 UTC, learnfirst1 wrote:
how to make this more fast like with one loop and get the
results.
thanks for reply, minimal perfect hashing seems good for this
task, I will do more test for confirm.
I try to storage the value into a static array, so when diff
middleware try access the key it will reused the array offset
without need to run hash on key string. (all middleware can
access the key by static enum name).
with Perfect Hash Function, I can translate the hash number into
static enum and use them.
The code also need provide string get(string key) method, in this
case the header key may not on the static preset arrays, in this
case it should search a smaller array (save on the parse
process). with this solution I has to run hash for each of
request headers , with less than 127 items (maybe around 16 at
max) I am not sure it is fast then direct string compare. for
example:
foreach(int header_index, ref header; new_request.headers) {
int hash = mpfh(header.key);
auto enum_index = static_eum[ hash ];
new_request.header[enum_index] = header_index ;
}
the simple static switch is not the best way as I know here.
with compiled PCRE match it will "Context-Type",
"Context-Encoding" in once ( and maybe there is some SSE4 to pass
16 byte for each loop).
Diederik de Groot
please ignore the Header.data assign part. which just for the
demo. in the real app it will only parse once and storage in pre
-alloc request/response object.
Re: Cannot use UFCS in lambda?
The problem is more general: you can only use top-level symbols in UFCS. You can use an identity alias template to bypass this: https://blog.thecybershadow.net/2015/04/28/the-amazing-template-that-does-nothing/ (search for UFCS in the page). Good to know. :-)
Re: try find the fastest way to convert a group string into index?
Homework ? I think it would also be better to only walk/match the Header.data and header_keys only once (using the generated switch statement that Vladimir suggested). So your Headers struct should have a parse() function, which will match all of the headers to the keys and store them locally in a 'matches[Type] = string' array (aka map). Then the get() function can simply return matches[type] without any work. Other improvements/Bonus Points: - Because the parse() function is only called/initialize once, you could make the matches array immutable/const if. - Your Type enum and header_keys contain the same data, and if you are going to use Vlafimir's suggestion of using a mixin, you can stringify the enum names an use them instead. This way you don't have to keep anything in sync. - If these Headers are coming from a client over the internet, it might be wise to set and check some (arbitrary) bounds for header-length and content. You are currently blindly copying it and expecting it is 'clean/correct'. - Why copy the data to Header.data, instead of just providing it by ref to the get()/parse() function. You are copying it to then later indexing into Header.data using the map(). Why not copy/move piecemeal and assign them to an indexed array after inspecting/matching them. That could make for cleaner code and nicer API. (With two caveats: we could loose the original headers if we don't save them somewhere else and unmatched/unknown Header Types will not be copied).
Re: Mobile is the new PC and AArch64 is the new x64
On Sunday, 16 September 2018 at 04:47:11 UTC, Joakim wrote: On Sunday, 16 September 2018 at 01:03:27 UTC, Dave Jones wrote: I know a lot of people who did, which explains the 28% drop in PC sales since they peaked in 2011, the year after the iPad came out. Many of those people who used to buy PCs have switched to tablets and other mobile devices. Yet PC sales are up this year, mobile is down, and tablet sales have fallen for 3 years in a row. Eh, these are all mostly mature markets now, so slight quarterly dips or gains don't matter much anymore. What does it matter that PC sales were up 2-3% last quarter when 7 times as many smartphones and mobile devices were sold in that same quarter? Some analysts have predicted that PC sales will plateau at some point and if that's where we're at now then 30% drop in shipments is not death of the market. I say that almost 30% drop in PC sales over the last 7 years is mostly due to the rise of mobile. I think a large part of it is that PCs got fast enough for most people about 7-10 years ago. So it was a combination of mobile, and people no longer needing to get newer faster machines. The upgrade cycle moved from "I need a newer faster computer" to "I'll wait till my current system is worn out". (For a lot of people anyway) And just because there's been a trend for 5 or 6 years doesnt mean it will continue so inevitably. Sure, but these trends almost never reverse. ;) It doesnt need to reverse for "the PC is dead" to be false. I actually think most people would prefer a separate desktop and mobile device, whether that desktop is just the size of pack of cigarettes, or a big box with 5 fans in it. Why? Given how price-sensitive the vast majority of the computing-buying public is- that excludes the Apple sheeple who actually seem to get a hard-on from rising iPhone prices, all the better for them to show how much money they've lucked into by brandishing their "gold" iPhone ;) - I don't see most willing to spend twice on two devices, that could be replaced by just one. Until recently, they didn't have a choice, as you couldn't use your mobile device as a desktop, but the just-released devices I linked in the first post in this thread are starting to change that. Because for about £300 you can get an intel NUC system with 120GB SSD, which is more powerful and more upgradeable than your £700 mobile device. And some people still want that. And because most people have more than one TV, some have multiple phones, phones and tablets, and desktops, and multiple games consoles. And they still use them all in different situations. This "one device" thing is your preference and you're projecting it onto everyone else. Yes you can bring up examples of people who made mistakes predicting the future but that works both ways. You're just as guilty of seeing a two points and drawing a straight line though them. Except none of these examples or my own prediction are based on simple extrapolation between data points. Rather, we're analyzing the underlying technical details and capabilities and coming to different conclusions about whether the status quo is likely to remain. So I don't think any of us are "guilty" of your charge. Of course you are, you're making predictions and assuming the trends will continue, you assume the technical details are all important. Im saying they are only part of it, that people have requirements / preferences outside of how powerful the device is. Lots of people were predicting ebooks would kill the real book market a few years back, turns out people still prefer to have an actual paper book to read, ebooks peaked a few years ago and real books have been in growth ever since. That was people seeing a trend and assuming it would continue just like you are.
Re: try find the fastest way to convert a group string into index?
On Sunday, 16 September 2018 at 10:04:09 UTC, learnfirst1 wrote:
how to make this more fast like with one loop and get the
results.
This is a more general problem than any specific programming
language; you may want to look into perfect hashing:
https://en.wikipedia.org/wiki/Perfect_hash_function
There exists software to generate perfect hash functions, e.g.
GNU gperf:
https://www.gnu.org/software/gperf/
It looks like Basile wrote one for D:
https://github.com/BBasile/IsItThere
If you don't want to go that far, you can generate a string
switch using string mixins:
void main()
{
static immutable string[] keywords = ["foo", "bar", "baz"];
enum Keyword { foo, bar, baz }
Keyword parseKeyword(string s)
{
switch (s)
{
mixin({
string code;
foreach (keyword; keywords)
code ~= `case "` ~ keyword ~ `": return Keyword.` ~ keyword
~ `;`;
return code;
}());
default:
throw new Exception("No such keyword!");
}
}
assert(parseKeyword("bar") == Keyword.bar);
}
try find the fastest way to convert a group string into index?
The use case is translate http header key into enum. this is the current code : https://run.dlang.io/is/lpw29w In this fake code I only list a few headers, it should be more. but less then 128 and only include the a few codes. how to make this more fast like with one loop and get the results. I am think of use PCRE compile for this, but not sure how. It should also save the non default headers in to a new array, so when search non default headers will reduce the total size. I am plan to write a more fast http server with D betterC compare to vibed.
Re: Cannot use UFCS in lambda?
On Sunday, 16 September 2018 at 09:46:15 UTC, berni wrote: Where is my mistake? Lambdas are not the issue here. The problem is more general: you can only use top-level symbols in UFCS. You can use an identity alias template to bypass this: https://blog.thecybershadow.net/2015/04/28/the-amazing-template-that-does-nothing/ (search for UFCS in the page).
Cannot use UFCS in lambda?
The following program does not compile:
import std.stdio;
import std.algorithm;
struct A
{
struct S
{
int x;
}
const bool foo(in S s, in int k)
{
return s.xa.foo(3)).writeln;
}
}
void main()
{
A().bar();
}
I get (using rdmd):
test.d(18): Error: no property foo for type S
/usr/include/dmd/phobos/std/algorithm/iteration.d(1108):
instantiated from here: >FilterResult!(__lambda1, S[])
test.d(18):instantiated from here: filter!(S[])
When I replace the UFCS-Syntax in the lambda by a function call
it works:
[S(1),S(2),S(3),S(4),S(5)].filter!(a=>foo(a,3)).writeln;
Where is my mistake?
Re: array to string functional?
On Friday, 14 September 2018 at 20:43:45 UTC, SrMordred wrote:
On Friday, 14 September 2018 at 19:44:37 UTC, berni wrote:
a) I've got an int[] which contains only 0 und 1. And I want
to end with a string, containing 0 and 1. So [1,1,0,1,0,1]
should become "110101". Of course I can do this with a loop
and ~. But I think it should be doable with functional style,
which is something I would like to understand better. Can
anyone help me here? (I think a.map!(a=>to!char(a+'0')) does
the trick, but is this good style or is there a better way?)
Yes, that's fine. That gives you a range; if you want an array,
call array() with that expression. Also, since you know the
addition won't overflow, you can substitute the to!char call with
a cast (arr.map!(c => cast(char)(c + '0')).array).
Another option is to index a string literal: arr.map!(c =>
"01"[c]).array
auto a = [1,0,1,1,1,0,1,0,1,1,1,1,0];
a.map!(to!string)
.join("")
.chunks(4)
.map!(to!string) //don´t know why the chunks are not
already strings at this point ;/
.writeln;
That's needlessly complicated and inefficient; this will allocate
one string per array element.
If you don't need the result to be actual arrays, this works:
auto res = [1,0,1,1,1,0,1,0,1,1,1,1,0]
.map!(c => "01"[c])
.chunks(4);
assert(equal!equal(res, ["1011","1010","","0"]));
If you need a real array of arrays:
auto arr = res
.map!array
.array;
assert(arr == ["1011","1010","","0"]);
