Re: XDG-APP and D
On Friday, 22 April 2016 at 10:24:08 UTC, Dicebot wrote: On 04/21/2016 11:30 PM, Karabuta wrote: This whole sandbox apps seem interesting. Canonical also talking about snaps :) Meh, I can see why this concept is tempting for desktop systems but it makes me feel that 5 years from now I'll have to build my own Linux-From-Scratch distro to preserve kind of user experience I initially loved Linux for (minimal overhead, running same system on both your tiny media server and power desktop). "A runtime can be thought of as a /usr filesystem with fixed contents. When a bundled app gets run, the runtime it needs gets mounted at /usr." :( I don't know at what point dynamic libraries came to be considered harmful, but it certainly seems to be the case now. And even if they are dynamic inside the container, every program shipping an individual copy of the libs means they might as well be statically compiled into it.
Re: XDG-APP and D
On Saturday, 23 April 2016 at 13:56:45 UTC, Joseph Rushton Wakeling wrote: On Saturday, 23 April 2016 at 11:29:29 UTC, NX wrote: I will just leave it here: http://www.zdnet.com/article/linux-expert-matthew-garrett-ubuntu-16-04s-new-snap-format-is-a-security-risk/ This is FUD. There are no security risks with snappy packages that there aren't with any other existing Linux packaging systems. But that's more or less what he's saying though, if you read his original blog post. His gripe isn't that it's defect security-wise, but rather that it's being marketed as capital-s Safe. As long as programs run under the X protocol, everything is up for grabs. Snappy doesn't change that fact at all, so widely claiming it makes it impossible to steal data would be cherry-picking Mir behaviour. "Snaps are intended to make it easier to distribute applications for Ubuntu - they include their dependencies rather than relying on the archive, they can be updated on a schedule that's separate from the distribution itself and they're confined by a strong security policy that makes it impossible for an app to steal your data. At least, that's what Canonical assert. It's true in a sense - if you're using Snap packages on Mir (ie, Ubuntu mobile) then there's a genuine improvement in security. But if you're using X11 (ie, Ubuntu desktop) it's horribly, awfully misleading. Any Snap package you install is completely capable of copying all your private data to wherever it wants with very little difficulty. The problem here is the X11 windowing system. X has no real concept of different levels of application trust. Any application can register to receive keystrokes from any other application. Any application can inject fake key events into the input stream. An application that is otherwise confined by strong security policies can simply type into another window. An application that has no access to any of your private data can wait until your session is idle, open an unconfined terminal and then use curl to send your data to a remote site. As long as Ubuntu desktop still uses X11, the Snap format provides you with very little meaningful security. Mir and Wayland both fix this, which is why Wayland is a prerequisite for the sandboxed xdg-app design." Sandboxing is good but I'm not convinced shipping duplicates of libraries with each program is. Packages were meant to solve this and they do, though .so version conflicts is a thing (albeit a rare one).
Re: On the future of DIP1000
On Saturday, 27 August 2016 at 15:19:40 UTC, Bill Hicks wrote: On Saturday, 27 August 2016 at 05:57:25 UTC, Walter Bright wrote: We've never mocked Rust's safety features, although I have posted that they are too complex for D and desire a simpler system. "A disharmonic personality. Reading any amount of Rust code evokes the joke 'friends don't let friends skip leg day' and the comic imagery (https://www.google.com/search?q=friends+don%27t+let+friends+skip+leg+day=off=isch=u=univ=X=0CB0QsARqFQoTCM_ViveKhMkCFUfZPgodVsgLsA=1582=1352) of men with hulky torsos resting on skinny legs". --Andrei If that's not mockery, then how would you describe it? On my phone so can only speak from memory, but if it serves then he went on to equally criticise D for its warts and blemishes. It would be cherry-picking to ignore context and just say that he threw mockery at rust.
Re: Fix suggestions for missing imports // code-d 0.15.0 & workspace-d 2.9.1 released
On Tuesday, 13 December 2016 at 21:12:24 UTC, Anonymouse wrote: What am I doing wrong? Sorted it out over IRC, it seems the extension is disabled if you only open discrete files and not folders. https://github.com/Pure-D/code-d/issues/62
Re: Fix suggestions for missing imports // code-d 0.15.0 & workspace-d 2.9.1 released
On Monday, 12 December 2016 at 21:42:50 UTC, WebFreak001 wrote:
[...]
I cannot for the life of me get it to work on Arch. I have
workspace-d from the AUR and the rest of dcd, dscanner, dfmt, dub
etc from the official repositories. They're all reachable via
$PATH so I haven't touched the path settings in vscode.
dlang sources on Arch are placed all wonky, right next to each
other in /usr/include/dlang/dmd (with no subdirectory distinction
for phobos/druntime), so I have a local copy of them in
~/src/dlang/{phobos,druntime}. The settings point there.
"d.stdlibPath": [
"/home/zorael/src/dlang/druntime/import",
"/home/zorael/src/dlang/phobos"
],
What does work is dcd on the current file, so I get local
autocompletion but nothing from imports. Aside from syntax
highlighting that's all I can see happening. Should there be a
menu for D things here somewhere?
When trying to install it manually, the last node command exits
with errors. I'm not sure if that's relevant to when installing
it through vscode itself.
$ node ./node_modules/vscode/bin/compile
The vscode extension module got updated to TypeScript 2.0.x.
Please see
https://code.visualstudio.com/updates/v1_6#_extension-authoring
for instruction on how to migrate your extension.
$ echo $?
1
What am I doing wrong?
Re: past.code123.org new service for sharing D code.
On Friday, 23 June 2017 at 17:33:48 UTC, Suliman wrote: http://past.code123.org/ I did small paste-bin service for sharing D code. Now it's deep alpha it's powered by vibed. It's simply works and nothing more. It's support basic syntax highlighting (after page refresh) for few language besides D. I hope to finish it in next few days, but you can try use it's now. I do not plan to touch DB. Looks interesting. You really really want tab to properly indent though. Currently on Chromium 59 tabbing loses focus.
Re: GDC with D frontend 2.081.2
On Friday, 24 August 2018 at 08:30:35 UTC, Daniel Kozak wrote: On Friday, 24 August 2018 at 05:35:13 UTC, Eugene Wissner wrote: As some of you may know D frontend was merged into GDC some time ago and is up to date. D version currently supported by GDC is 2.081.2 and it can be found in "gdc-7" and "gdc-8" branches. I will say a bit more about GDC development and development plans later. [...] Btw. there are packages for archlinux on AUR gdc-8 with d frontend: https://aur.archlinux.org/packages/gdc/ gdc-8-stable with c++ frontend: https://aur.archlinux.org/packages/gdc-stable/ Is it supposed to be up to date in this sense? __VERSION__ is 2068L with Manjaro/Arch gdc 8.2.0-1.
Re: GDC with D frontend 2.081.2
On Saturday, 25 August 2018 at 20:59:56 UTC, Daniel Kozak wrote: Hmm I am not sure, but how long did you have this gdc package installed? It seems I forgot to update .SRCINFO. There should be gdc-8.2.0-2 which has 2.081.1 d frontend. I will fix this on monday, until than you can uninstall gdc and try to build it again. August 10th. I'll wait for -2 then. Installed Size : 243.72 MiB Packager: Unknown Packager Build Date : fre 10 aug 2018 01:24:01 Install Date: fre 10 aug 2018 15:10:09
Re: GDC with D frontend 2.081.2
On Monday, 27 August 2018 at 17:44:01 UTC, Iain Buclaw wrote: Raise a bug then? Iain. How are we supposed to file GDC bugs when bugzilla account creation is restricted? I even emailed you about it back in May, but I imagine I was filtered as spam.
Re: The New Fundraising Campaign
On Saturday, 19 January 2019 at 06:43:34 UTC, H. S. Teoh wrote: This forum is very functional. I would participate less in a forum that requires loading up a browser to use. But then again, maybe people would be happier if I wasn't around to blab about vim and symmetry and why dub sux, so perhaps that might be for the better. :-P T For us on the browser pages don't always load, though.
Re: DLP identify leaf functions
On Friday, 30 November 2018 at 20:10:05 UTC, Jacob Carlborg wrote:
I would like to announce a new project I've started, called DLP
(D Language Processing). Currently it's quite experimental but
the idea is that it would contain a collection of commands for
inspecting D code in various ways. It uses the DMD frontend as
a library (the Dub package) to process D code.
Looks interesting.
My project requires a bunch of version identifiers to actually
compile. Is there a way to pass these, or ideally a way to make
it parse them from dub.{json,sdl}?
Re: NEW Milestone: 1500 packages at code.dlang.org
On Thursday, 7 February 2019 at 10:14:18 UTC, Martin Tschierschke wrote: Hi all, I am very happy to be the first to announce this here: 1500 D packages available via DUB at code.dlang.org ! Great! Now as the pure volume of solutions gets more and more impressive, we have to find better ways to enhance quality and stability. The "Score" indicator is a very good step. A field, probably at first just manually set by the owner, giving latest tested dmd version might give a good way to filter for well maintained packages. My second wish is to start a general effort to adopt several packages by D Foundation to ensure they keep updated. What was the word on the autotester (or similar) testing popular packages as part of the test suite?
kameloso IRC bot
Announcing kameloso IRC bot, 1.0.0.
It's a bot, not a parser library, though the parsing can
technically be lifted out and reused.
On GitHub: https://github.com/zorael/kameloso, also
https://kameloso.dub.pm.
There's notes to offline users, pasted URL title lookup, logs,
automatic mode sets (e.g. +o on join), s/this/that/ substitution,
user quotes, !seen, a basic Twitch streamer plugin. Some other
legacy features and trivialities like the original venerable echo
command. Ideas needed.
Absolute bare minimum required to try it:
git clone https://github.com/zorael/kameloso.git
cd kameloso
dub build
./kameloso --channels "#d,#freenode,##linuxmint"
With no other settings this will just be in client mode as a
guest user and won't pollute the channels. (#d alone is too quiet
to make a good example.) ./kameloso --writeconfig to set up
further, see --help and the readme. Windows Powershell/cmd users
may need an extra step to get terminal colours instead of \033[0m
everywhere, see the readme.
The MVPs here are definitely UDAs, slices and mixin templates.
There are some clever things in there that I'm really proud of,
and some blemishes that I've learned to live with.
dscanner --sloc weighs it in at ~11k lines, excluding most tests.
Much of it is @safe but it's not @nogc, nor -betterC. Naturally
it tries to avoid allocating low-hanging fruit but there's
Exceptions, associative and dynamic arrays, string
concatenations, closures, and all kinds of convenient D things.
Parsing looks like this (automatically generated unit test):
https://github.com/zorael/kameloso/commit/dde05a06
Plugins like this (automatically called module-level function):
@(IRCEvent.Type.CHAN)
@(PrivilegeLevel.anyone)
@(ChannelPolicy.home)
@BotCommand(PrefixPolicy.prefixed, "hello")
@BotCommand(PrefixPolicy.nickname, "poke")
@Description("Sends a hello world to the current channel.")
void onCommandHello(MyPlugin plugin, const IRCEvent event)
{
plugin.chan(event.channel, "Hello world!");
}
Because of how code.dlang.org and dub deals with versions
(announces pre-releases but serves releases), having previously
pulled this from there at any point up until now will have landed
you with an ancient version. So please don't judge this by any
previous builds.
A normal dub build takes 9 seconds with dmd on this laptop
(Linux) and eats 4036 Mb of RAM, down from 7800+ Mb. Profiling
does not seem to show any particular surprising hotspots anymore.
All compilers segfault in various situations[1][2][3].
Feedback appreciated.
[1]: https://issues.dlang.org/show_bug.cgi?id=18026
[2]: https://issues.dlang.org/show_bug.cgi?id=19123
[3]: https://bugzilla.gdcproject.org/show_bug.cgi?id=307
Re: kameloso IRC bot
On Saturday, 2 February 2019 at 15:45:11 UTC, Anonymouse wrote: Announcing kameloso IRC bot, 1.0.0. [...] Tagging v1.2.0. https://github.com/zorael/kameloso It's been a while so diffs everywhere. One plugin was merged into another, a third was broken out of a fourth. Small tweaks, more clever things. Queued sends should not block the client by sleeping anymore. A few crashes fixed. Compilation memory use grew some. Binary size did too. There's more Twitch stuff, but it remains optional at compilation since it's nothing you're going to use. As before, all plugins can be opted out from being compiled at all, by choice of dub build configuration or by manually tailoring dub.json[1]. So it's as lean as you want it to be. (Still pretty big.) Plugins not crucial for the bot to properly operate can also be disabled at runtime, even if built, in the configuration file. https://github.com/zorael/kameloso/blob/master/source/kameloso/plugins/hello.d [1]: https://github.com/zorael/kameloso/blob/c00af3b9/dub.json#L22-L38 A week in 25 channels: [...] ^C...caught signal 2! [12:35:23] Aborting... Number of collections: 8 Total GC prep time: 0 milliseconds Total mark time: 42 milliseconds Total sweep time: 2 milliseconds Max Pause Time: 10 milliseconds Grand total GC time: 46 milliseconds GC summary: 176 MB,8 GC 46 ms, Pauses 43 ms < 10 ms ./kameloso --DRT-gcopt=profile:1 419.10s user 1243.21s system 0% cpu 180:06:10.53 total avg shared (code): 0 KB avg unshared (data/stack): 0 KB total (sum): 0 KB max memory:204 MB page faults from disk: 0 other page faults: 6156
Re: allow response status codes with curl
On Thursday, 3 October 2019 at 01:02:43 UTC, Hampus wrote: I have a program that is using std.curl and right now if a http request returns a status code other than 200 the program will crash like this: std.net.curl.HTTPStatusException@C:\D\dmd2\windows\bin\..\..\src\phobos\std\net\curl.d(1082): HTTP request returned status code 404 (Not Found) What I want to do is allow certain stauts codes and I want my program to keep going if it receives for example 404 or 500 but raise an exception for lets say status code 403. How do I achieve this? The HTTPStatusException class has a `.status` int member that contains the returned status code. Is that what you're looking for? https://dlang.org/library/std/net/curl/http_status_exception.html Also this thread belongs in the Learn forum.
Re: dlang-requests 1.1.0 released
On Sunday, 5 April 2020 at 08:59:50 UTC, ikod wrote: Hello! Just a note that dlang-requests ver 1.1.0 released with new 'ByLine' interfaces added for get/post/put requests. [...] As always, thanks for your hard work! I don't use much more than the normal `get` and `receiveAsRange`, but it's been working well.
Re: Release D 2.091.0
On Tuesday, 10 March 2020 at 13:24:41 UTC, Martin Nowak wrote: Glad to announce D 2.091.0, ♥ to the 55 contributors. This release comes with 64-bit Windows binaries, improvements on C++ integrations, a @safe std.bigint, and various bugfixes. http://dlang.org/download.html http://dlang.org/changelog/2.091.0.html -Martin Looking forward to it, but curiously still no updates to the Arch Linux package repositories... https://www.archlinux.org/packages/community/x86_64/dmd/
Re: Release D 2.094.0
On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: Glad to announce D 2.094.0, ♥ to the 49 contributors. This release comes with faster compiler binaries (built with ldc), direct git dependencies in dub, better type checking of vectors, and improved template instantiation diagnostics. http://dlang.org/download.html http://dlang.org/changelog/2.094.0.html -Martin Binaries took a while to hit Arch repositories, but now they did and I'm immediately pleasantly surprised. 2.093.1: $ time dub build -c dev Performing "debug" build using dmd for x86_64. [...] max memory:3598 MB 2.094.0: $ time dub build -c dev Performing "debug" build using dmd for x86_64. [...] max memory:3277 MB Is it because of dmd being built with ldc?
Re: LDC 1.24.0
On Saturday, 7 November 2020 at 23:54:51 UTC, Dan Printzell wrote: Sorry, I've been waiting for the LLVM 11 package rebuild[1] to finish to make the packaging easier. But as so much time have passed I should probably just do it anyway. [1] https://www.archlinux.org/todo/llvm-11/ I see they hit the repositories yesterday. Thanks!
Re: LDC 1.24.0
On Saturday, 24 October 2020 at 15:11:08 UTC, kinke wrote: [...] Arch Linux packages are still at 1.23[1]. They were flagged as outdated on Oct 25th. Does anyone know the package maintainers? Is there something blocking an update? [1]: https://www.archlinux.org/packages/community/x86_64/ldc/
Re: requests 2.0.0 release
On Thursday, 29 October 2020 at 06:42:54 UTC, ikod wrote: Hi, requests 2.0.0 released with single change - support for vibe-d moved to separate subpackage. Thanks for all your hard work! This was an annoying point and I'm happy to see a solution that works for everyone.
kameloso IRC bot 2.0.0
kameloso is an IRC bot based on mixins and UDAs. It's available on GitHub at https://github.com/zorael/kameloso, or you can fetch and run it directly via dub. ``` dub run kameloso -- --nickname dman --server irc.freenode.net --homeChannels "#dmanfans" --guestChannels "#d,#freenode" ``` Add --monochrome to disable terminal colours. --help does what you'd expect it to, but you need to generate a configuration file to access all settings. See the README for help on getting started. Ask me anything. All feedback appreciated!
Re: argparse version 0.7.0 - a CLI parsing library
On Friday, 18 March 2022 at 19:09:27 UTC, Adam D Ruppe wrote: On Friday, 18 March 2022 at 18:21:46 UTC, Anonymouse wrote: One drawback is documentation; adrdox does *not* like these kinds of UDAs. It is on my list to run big UDAs through the auto-formatter at some point pretty soon to help with this. I just have a big work project I'm wrapping up first. Sweet!
Re: Added copy constructors to "Programming in D"
On Saturday, 8 January 2022 at 02:07:10 UTC, Ali Çehreli wrote: 2) The other noteworthy change in the book is my now-different stance on variables: Now I recommend 'const' over 'immutable' for variables. I'm curious, could you elaborate a bit on this? I skimmed through the page on Immutability but I didn't find anything explaining it.
Re: reggae v0.10.0 - The meta build system just got better
On Thursday, 7 September 2023 at 17:34:48 UTC, Atila Neves wrote: [...] Can reggae handle non-trivial dub builds with trees of dependencies? I gave it a quick test, following the examples in the readme, and the Makefile it generated looked for sources in the wrong place. It also didn't build the dependencies (nor even include their source directories as import paths). Maybe I'm doing it wrong.
Re: argparse version 0.7.0 - a CLI parsing library
On Thursday, 17 March 2022 at 19:07:28 UTC, H. S. Teoh wrote:
Using independent, orthogonal UDAs may make option
specification using your module easier to read. For example,
from your docs:
struct T {
@(NamedArgument
.PreValidation!((string s) { return s.length > 1 && s[0] ==
'!'; })
.Parse!((string s) { return s[1]; })
.Validation !((char v) { return v >= '0' && v <= '9';
})
.Action !((ref int a, char v) { a = v - '0'; })
)
int a;
}
could be rewritten with multiple UDAs as:
struct T {
@NamedArgument
@PreValidation!((string s) { return s.length > 1 && s[0] ==
'!'; })
@Parse!((string s) { return s[1]; })
@Validation !((char v) { return v >= '0' && v <= '9'; })
@Action!((ref int a, char v) { a = v - '0'; })
int a;
}
It might also simplify your implementation by having more
smaller, independent pieces for each UDA instead of a single
complex UDA that handles everything.
I use UDAs extensively in my project and I've historically been
doing the multiple-UDA approach you describe. Upon seeing
argparse a few months back I started rewriting it to use a single
UDA, and I found it allowed for a simpler implementation (and not
the other way around).
The immediate gains boiled down to that I could now pass what is
essentially a context struct around at CTFE instead of keeping
track of multiple variables. Default values are also much easier
to manage with much fewer `hasUDA`s sprinkled everywhere.
One drawback is documentation; adrdox does *not* like these kinds
of UDAs.
Re: GCC 12.1 Released (D v2.100-rc.1)
On Friday, 6 May 2022 at 11:57:47 UTC, Iain Buclaw wrote: Hi, I am proud to announce another major GCC release, 12.1. This year, the biggest change in the D front-end is the version bump from v2.076.1 to **[v2.100.0-rc.1](https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=b4acfef1342097ceaf10fa935831f8edd7069431)**. For the full list of front-end changes, please read the [change log on dlang.org](https://dlang.org/changelog/2.100.0.html). As and when DMD releases new minor releases of v2.100.x, they will be backported into the next minor release of GCC. Amazing, congratulations! I was hammering the Arch Linux package page for `gcc-d` waiting for the update to show up there, but it went from 11.2.0-4 to deleted. gcc-d 11.2.0-4 has been removed from the [core] repository. Does anyone know what's going on there?
Re: Beta 2.101.0
On Monday, 17 October 2022 at 11:35:22 UTC, Iain Buclaw wrote: [...] Thanks! Question. From the changelog; Posix (excl. Darwin): Switch default GC signals from SIGUSR1/2 to SIGRTMIN/SIGRTMIN+1 What should I tell gdb to handle to catch those? `SIG33` and `SIG34`?
Re: New WIP DUB documentation
On Monday, 15 August 2022 at 21:32:23 UTC, WebFreak001 wrote: [...] I like it! Can anything be done about the width of the `buildOptions` table though? The whole page takes up about about half of my horizontal screen real estate, yet the "corresponding GDC flags" column is still partially out of view until I scroll right. I'm on a laptop so I can do horizontal scrolls by gesture, but I imagine a user with only vertical scrolling has to navigate all the way down to the bottom of the table to get the horizontal scroll bar to show? (I don't know how to solve it neatly but I thought I'd mention it.)
Re: Beta 2.104.0
On Wednesday, 10 May 2023 at 02:48:02 UTC, anonymouse wrote: On Tuesday, 2 May 2023 at 00:34:45 UTC, Iain Buclaw wrote: Glad to announce the first beta for the 2.104.0 release, ♥ to the 36 contributors. A couple days ago I ran into an issue that was solved by https://issues.dlang.org/show_bug.cgi?id=23846 so I upgraded to this beta. Note: The same does not happen with LDC ``` (ldc-1.32.1)confuzzled@confuzzleds-MBP stat % dub Starting Performing "debug" build using /Users/confuzzled/dlang/ldc-1.32.1/bin/ldc2 for x86_64. Building mir-core 1.5.5: building configuration [library] Building mir-algorithm 3.20.2: building configuration [default] Building mir-stat 0.1.6: building configuration [library] Building stat ~master: building configuration [application] Linking stat Running stat Edit source/app.d to start your project. ```
Re: Beta 2.104.0
On Wednesday, 10 May 2023 at 03:57:59 UTC, anonymouse wrote: On Wednesday, 10 May 2023 at 03:31:05 UTC, thinkunix wrote: Not sure if that helps, but it shows this works with dmd-2.104.0-beta.1 at least on Linux x86_64. scot I think that worked for you because although you have set mirstat as a dependency, you are not actually linking against it. Try `import mir.stat;` into app.d and rebuild. -- anonymouse Also it might be a macOS specific issue since the original problems I faced didn't materialize on my Debian 11 VM.
Re: Beta 2.104.0
On Wednesday, 10 May 2023 at 03:57:59 UTC, anonymouse wrote: I think that worked for you because although you have set mirstat as a dependency, you are not actually linking against it. Try `import mir.stat;` into app.d and rebuild. -- anonymouse Ignore that... Just saw your comment regard editing app.d
Re: Beta 2.104.0
On Tuesday, 2 May 2023 at 00:34:45 UTC, Iain Buclaw wrote:
Glad to announce the first beta for the 2.104.0 release, ♥ to
the 36 contributors.
A couple days ago I ran into an issue that was solved by
https://issues.dlang.org/show_bug.cgi?id=23846 so I upgraded to
this beta. I just initialized a dub project to try to use
```mir.stat```
```D
import std.stdio;
import mir.stat;
void main()
{
writeln("Edit source/app.d to start your project.");
}
```
and ran into the following linker errors:
```
(dmd-2.104.0-beta.1)confuzzled@confuzzleds-MBP stat % dub
Starting Performing "debug" build using
/Users/confuzzled/dlang/dmd-2.104.0-beta.1/osx/bin/dmd for x86_64.
Up-to-date mir-core 1.5.5: target for configuration [library]
is up to date.
Up-to-date mir-algorithm 3.20.2: target for configuration
[default] is up to date.
Up-to-date mir-stat 0.1.6: target for configuration [library]
is up to date.
Building stat ~master: building configuration [application]
Linking stat
ld: warning: alignment (1) of atom 'anon' is too small and may
result in unaligned pointers
[SNIP same ld error repeated 1697 times]
ld: warning: alignment (1) of atom 'anon' is too small and may
result in unaligned pointers
ld: warning: pointer not aligned at address 0x10006C2A1 ('anon' +
673 from
/Users/confuzzled/.dub/cache/stat/~master/build/application-debug-d2OWm2um2jTdPTUfJ52drA/stat.o)
ld: warning: pointer not aligned at address 0x10006C2BE ('anon' +
702 from
/Users/confuzzled/.dub/cache/stat/~master/build/application-debug-d2OWm2um2jTdPTUfJ52drA/stat.o)
ld: warning: pointer not aligned at address 0x10006C3A1 ('anon' +
929 from
/Users/confuzzled/.dub/cache/stat/~master/build/application-debug-d2OWm2um2jTdPTUfJ52drA/stat.o)
ld: warning: pointer not aligned at address 0x10006C3E9 ('anon' +
1001 from
/Users/confuzzled/.dub/cache/stat/~master/build/application-debug-d2OWm2um2jTdPTUfJ52drA/stat.o)
ld: warning: pointer not aligned at address 0x10006C43F ('anon' +
1087 from
/Users/confuzzled/.dub/cache/stat/~master/build/application-debug-d2OWm2um2jTdPTUfJ52drA/stat.o)
ld: warning: pointer not aligned at address 0x10006C47A ('anon' +
1146 from
/Users/confuzzled/.dub/cache/stat/~master/build/application-debug-d2OWm2um2jTdPTUfJ52drA/stat.o)
ld: warning: pointer not aligned at address 0x10006C496 ('anon' +
1174 from
/Users/confuzzled/.dub/cache/stat/~master/build/application-debug-d2OWm2um2jTdPTUfJ52drA/stat.o)
ld: warning: pointer not aligned at address 0x10006C4D2 ('anon' +
1234 from
/Users/confuzzled/.dub/cache/stat/~master/build/application-debug-d2OWm2um2jTdPTUfJ52drA/stat.o)
ld: warning: pointer not aligned at address 0x10006C6FD ('anon' +
122 from
../../.dub/cache/mir-algorithm/3.20.2/build/default-debug-R1enIlTUL3xo2uXB-nJMrg/libmir-algorithm.a(lifetime_fd_8f7.o))
ld: warning: pointer not aligned at address 0x10006C8A3 ('anon' +
127 from
../../.dub/cache/mir-algorithm/3.20.2/build/default-debug-R1enIlTUL3xo2uXB-nJMrg/libmir-algorithm.a(hash_114_3c9.o))
ld: warning: pointer not aligned at address 0x10006C93B ('anon' +
127 from
../../.dub/cache/mir-algorithm/3.20.2/build/default-debug-R1enIlTUL3xo2uXB-nJMrg/libmir-algorithm.a(hash_125_58c.o))
ld: warning: pointer not aligned at address 0x10006CAB9 ('anon' +
139 from
../../.dub/cache/mir-algorithm/3.20.2/build/default-debug-R1enIlTUL3xo2uXB-nJMrg/libmir-algorithm.a(comparison_186_3bd.o))
ld: warning: pointer not aligned at address 0x10006CB56 ('anon' +
129 from
../../.dub/cache/mir-algorithm/3.20.2/build/default-debug-R1enIlTUL3xo2uXB-nJMrg/libmir-algorithm.a(string_187_36f.o))
ld: warning: pointer not aligned at address 0x10006CC9D ('anon' +
142 from
../../.dub/cache/mir-algorithm/3.20.2/build/default-debug-R1enIlTUL3xo2uXB-nJMrg/libmir-algorithm.a(concatenation_219_e62.o))
ld: warning: pointer not aligned at address 0x10006CD67 ('anon' +
137 from
../../.dub/cache/mir-algorithm/3.20.2/build/default-debug-R1enIlTUL3xo2uXB-nJMrg/libmir-algorithm.a(capacity_21a_11f9.o))
ld: warning: pointer not aligned at address 0x10006CE0F ('anon' +
142 from
../../.dub/cache/mir-algorithm/3.20.2/build/default-debug-R1enIlTUL3xo2uXB-nJMrg/libmir-algorithm.a(concatenation_21b_1145.o))
ld: warning: pointer not aligned at address 0x10006CFE2 ('anon' +
151 from
../../.dub/cache/mir-algorithm/3.20.2/build/default-debug-R1enIlTUL3xo2uXB-nJMrg/libmir-algorithm.a(atomic_2d0_104b.o))
ld: warning: pointer not aligned at address 0x10006D191 ('anon' +
127 from
../../.dub/cache/mir-core/1.5.5/build/library-debug-6QbncWne9XfURo0c-rzF0g/libmir-core.a(hash_30_76c.o))
ld: unaligned pointer(s) for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to
see invocation)
Error: linker exited with status 1
Error /Users/confuzzled/dlang/dmd-2.104.0-beta.1/osx/bin/dmd
failed with exit code 1.
```
Re: exponential errors
On Monday, 8 May 2023 at 10:24:53 UTC, Dennis wrote: It has been fixed, but you'll need to update to 2.104.0 which is currently in beta. Confirmed. installed 2.104.0-beta.1 and everything's now back to normal. Thank you. -- anonymouse
Re: Beta 2.104.0
On Wednesday, 10 May 2023 at 03:31:05 UTC, thinkunix wrote: Not sure if that helps, but it shows this works with dmd-2.104.0-beta.1 at least on Linux x86_64. scot I think that worked for you because although you have set mirstat as a dependency, you are not actually linking against it. Try `import mir.stat;` into app.d and rebuild. -- anonymouse
Re: Beta 2.104.0
On Wednesday, 10 May 2023 at 10:22:23 UTC, jmh530 wrote: mir-stat also doesn't include mac os as part of the test suite (mir-algorithm does). PRs are welcome. Actually, it happens even when you don't import anything. As for PRs, I would if I could. Although I've been around the community for a while, I'm definitely the most unskilled member here. Just got ticked off at myself over the weekend and picked up my first stats book ever with the intent to build a solid foundation and gain the skills necessary to help out. --anonymouse
Re: Beta 2.104.0
On Wednesday, 10 May 2023 at 12:34:00 UTC, Steven Schveighoffer wrote: This reminds me of an LDC bug fixed recently. I bet DMD suffers from a similar problem: https://github.com/ldc-developers/ldc/issues/3864 -Steve And it is. Just tried the workaround proposed (export MACOSX_DEPLOYMENT_TARGET=11) and it resolved the issue. Thank you. -- anonymouse
exponential errors
I'm not the sharpest tool in the shed so I would really
appreciate some assistance clarifying what's going on here and
how to accomplish this seemingly simple (to me) goal.
I'd like to raise a floating point value ```d``` to some exponent
```n```.
Never thought I'd have to do this but, in Python:
```Python
pow(1/2, 3)
```
output:
```
0.125
```
in D:
```D
import std.stdio;
void main()
{
writeln((1/2)^^3);
}
```
Compile Time Error:
```
hist.d(40): Error: undefined identifier `pow` in module `std.math`
```
Say what? I don't remember ever calling `import std.math : pow`.
Why am I getting this error?
Okay, whatever, just import the damn thing
```D
import std.stdio;
void main()
{
writeln((1/2)^^3);
import std.math.exponential: pow; // placement intentional,
ran into this error
// by accident while trying
to understand the
// error above and the one
to come next at the
// same time
}
```
Compile Time Error:
```
/Users/confuzzled/dlang/dmd-2.103.0/osx/bin/../../src/phobos/std/math/exponential.d(47):
Error: version `InlineAsm_X86_Any` defined after use
```
Come again? Okay, good to know I guess. Let's get it right this
time.
```D
import std.stdio;
void main()
{
import std.math.exponential: pow;
writeln((1/2)^^3);
// I was actually trying to use pow() here directly
// which produced the same errors as below when I ran into the
// previous error
}
```
Compile Time Error:
```
/Users/confuzzled/dlang/dmd-2.103.0/osx/bin/../../src/phobos/std/math/exponential.d(3791): Error: number `0x0.8p-126f` is not representable as a `float`
/Users/confuzzled/dlang/dmd-2.103.0/osx/bin/../../src/phobos/std/math/exponential.d(3791):https://dlang.org/spec/lex.html#floatliteral
/Users/confuzzled/dlang/dmd-2.103.0/osx/bin/../../src/phobos/std/math/exponential.d(3791): Error: number `0x0.8p-126f` is not representable as a `float`
/Users/confuzzled/dlang/dmd-2.103.0/osx/bin/../../src/phobos/std/math/exponential.d(3791):https://dlang.org/spec/lex.html#floatliteral
/Users/confuzzled/dlang/dmd-2.103.0/osx/bin/../../src/phobos/std/math/exponential.d(3793): Error: number `0x0.56p-126f` is not representable as a `float`
/Users/confuzzled/dlang/dmd-2.103.0/osx/bin/../../src/phobos/std/math/exponential.d(3793):https://dlang.org/spec/lex.html#floatliteral
/Users/confuzzled/dlang/dmd-2.103.0/osx/bin/../../src/phobos/std/math/exponential.d(3793): Error: number `0x0.56p-126f` is not representable as a `float`
/Users/confuzzled/dlang/dmd-2.103.0/osx/bin/../../src/phobos/std/math/exponential.d(3793):https://dlang.org/spec/lex.html#floatliteral
/Users/confuzzled/dlang/dmd-2.103.0/osx/bin/../../src/phobos/std/math/exponential.d(3804): Error: number `0x0.8p-1022` is not representable as a `double`
/Users/confuzzled/dlang/dmd-2.103.0/osx/bin/../../src/phobos/std/math/exponential.d(3804):`real` literals can be written using the `L` suffix. https://dlang.org/spec/lex.html#floatliteral
/Users/confuzzled/dlang/dmd-2.103.0/osx/bin/../../src/phobos/std/math/exponential.d(3804): Error: number `0x0.8p-1022` is not representable as a `double`
/Users/confuzzled/dlang/dmd-2.103.0/osx/bin/../../src/phobos/std/math/exponential.d(3804):`real` literals can be written using the `L` suffix. https://dlang.org/spec/lex.html#floatliteral
/Users/confuzzled/dlang/dmd-2.103.0/osx/bin/../../src/phobos/std/math/exponential.d(3806): Error: number `0x0.5p-1022` is not representable as a `double`
/Users/confuzzled/dlang/dmd-2.103.0/osx/bin/../../src/phobos/std/math/exponential.d(3806):`real` literals can be written using the `L` suffix. https://dlang.org/spec/lex.html#floatliteral
/Users/confuzzled/dlang/dmd-2.103.0/osx/bin/../../src/phobos/std/math/exponential.d(3806): Error: number `0x0.5p-1022` is not representable as a `double`
/Users/confuzzled/dlang/dmd-2.103.0/osx/bin/../../src/phobos/std/math/exponential.d(3806):`real` literals can be written using the `L` suffix. https://dlang.org/spec/lex.html#floatliteral
```
I'm sorry, what am I missing? How do I accomplish this task?
-- anonymouse
Re: exponential errors
On Monday, 8 May 2023 at 03:22:02 UTC, anonymouse wrote: Sorry, I thought I was already in the Learn forum. Please move there if possible.
Re: exponential errors
On Monday, 8 May 2023 at 04:13:11 UTC, NonNull wrote:
On Monday, 8 May 2023 at 03:22:02 UTC, anonymouse wrote:
Never thought I'd have to do this but, in Python:
```Python
pow(1/2, 3)
```
output:
```
0.125
```
in D:
```D
import std.stdio;
void main()
{
writeln((1/2)^^3);
}
Using DMD64 D Compiler v2.103.0:
The above program ran and output ```0``` because ```1/2``` is
zero in D as that's integer division. Putting 1.0 instead of 1,
it output ```0.125```.
Your compiler version is?
Fare enough regarding integer division, I used 1/2 in python when
I switch to check my sanity and carried it forward when I came
back to D but the results were the exact same. Errors vice the
outputs you posted above. The actual code that triggered this was
```D
double d = 0.5;
int n = 3;
writeln(d ^^ n);
```
As for the version of D I'm using, according to ```dmd
--version``` it is none other than
DMD64 D Compiler v2.103.0
Not sure if it makes a difference but I'm using MacOS Ventura.
Re: exponential errors
On Monday, 8 May 2023 at 04:31:37 UTC, anonymouse wrote: ``` As for the version of D I'm using, according to ```dmd --version``` it is none other than DMD64 D Compiler v2.103.0 Not sure if it makes a difference but I'm using MacOS Ventura. Removed and install v2.103.1, but experiencing the exact same issues.
Re: exponential errors
On Monday, 8 May 2023 at 04:31:37 UTC, anonymouse wrote: As for the version of D I'm using, according to ```dmd --version``` it is none other than DMD64 D Compiler v2.103.0 Not sure if it makes a difference but I'm using MacOS Ventura. This is a macOS issue. Don't know if it's specific to Ventura but I just loaded up a Debian VM and it runs as expected.
Re: Browsers in D
On Wednesday, 20 December 2023 at 06:29:30 UTC, Hors wrote: Rust is better choice than D if you have to run code from untrusted resources (html, javascript, webassembly...) it's safer, plus faster. [citation needed]
Re: Beta 2.108.0
On Saturday, 2 March 2024 at 17:40:29 UTC, Iain Buclaw wrote:
[...]
Named arguments for functions have been implemented and
documented
Yay, I was really looking forward to this.
I currently use `std.typecons.Flag` virtually *everywhere* to
make sure I don't confuse parameters.
```d
auto doThing(
const string what,
const Flag!"foo" foo,
const Flag!"bar" bar,
const Flag!"baz" baz = No.baz)
{
// ...
}
auto thing = doThing("asdf", Yes.foo, No.bar, Yes.baz);
```
It will take some time adapting to but I welcome the addition.
Re: D Language Foundation December 2023 Monthly Meeting Summary
On Wednesday, 27 March 2024 at 20:32:16 UTC, Mike Parker wrote: [...] Thank you for summarising these!
