Re: bool (was DConf 2019 AGM Livestream)
On Sunday, 12 May 2019 at 06:27:21 UTC, Nick Sabalausky (Abscissa) wrote: All this effort strongly implies that there's no such thing as a satisfactory bool type *in languages which conflate booleans with integers* FWIW I write C# for food and to me D bool is better than C# bool. Didn't watch, but if it's about the DIP I think of, its rationale was overload rules, Walter said he's not opposed to tune them. It was derailed into discussion about strong bool?
Re: Phobos is now compiled with -preview=dip1000
On Wednesday, 15 May 2019 at 07:56:48 UTC, Walter Bright wrote: Maybe the clock is not synchronized somewhere. It's off by one hour.
Re: Phobos is now compiled with -preview=dip1000
On Thursday, 16 May 2019 at 05:22:42 UTC, Seb wrote: Yes that sounds like the culprit. Btw as mentioned on DConf, the dip1000 switch contains a few other breaking changes which will make it even harder to adopt too. Well, it's an inherent property of DIP1000 to not compile code that previously compiled. Though safety of tupleof shouldn't depend on DIP1000.
Re: Priority DIP for Draft Review: Argument Ownership and Function Calls
On Friday, 28 June 2019 at 07:22:56 UTC, Olivier FAURE wrote: I'm particularly interested in flow analysis features, and I think I have something to contribute, but I don't want to spend a large amount of effort debating and suggesting alternatives if I expect to be stonewalled. It seems general fear of flow analysis is that people will ask it to be perfect and it would be difficult to stop it from growing in complexity.
Re: I was able to write some D last week!
From an earlier post: In particular, nginx can do a scgi proxy with a unix socket and this may be easier to use with your firewall and filesystem permissions. Oh, I tried it. First nginx didn't find the socket. Guess why? Because nginx runs in a virtualized filesystem. Relocated the socket, now nginx says access denied, sure nginx and your server can run under different accounts, permissions should be tweaked accordingly, tweaked them, still access denied, relocated the socket a bit more, still access denied. Guess why? I turned out to be some kind of audit, selinux or something like that, it just fails with generic access denied error. Ok, FHS recommends /var/run, but it's rwxr-xr-x root root. Wut? Run a network server as root? Tried tcp, it just works.
Re: Release D 2.087.0
On Monday, 15 July 2019 at 19:20:27 UTC, Johannes Pfau wrote: I wonder how you can advertise this as a good idea: You have to manually keep declarations in sync, you have to be very careful to get the attributes right, module constructor evaluation order guarantees don't hold, no mangling (no type safety), you pollute the C namespace, no inlining, no templates. This is an established workaround at best, in no way it's a good solution. Was there an agreement that arbitrary amount of code imported in object.d doesn't impact compilation speed or such impact is unimportant?
Re: Tracing D Applications
On Friday, 13 March 2020 at 19:00:01 UTC, Mike Parker wrote: Blog: https://dlang.org/blog/2020/03/13/tracing-d-applications/ The term "production" there seemingly means "the developer that wrote the program is also an administrator of all production systems" :)
Re: LDC 1.23.0-beta1
Just found an old bug. Atomics modify immutable data:
---
import ldc.intrinsics;
void f(immutable int* a)
{
llvm_atomic_rmw_add(a,1);
}
---
Re: LDC 1.24.0-beta1
On Tuesday, 20 October 2020 at 20:09:58 UTC, aberba wrote: Supposing I'm new to D, I have previous experience with LLVM-based compilers so I prefer to use LDC. How am I supposed to know what to do? Where is the information on how to get it on my system through visualD installer? The LDC experience needs some improvement here. Supposedly they will want an IDE with everything included in one installer, like Visual Studio, and that's what VisualD installer apparently does.
Re: LDC 1.24.0-beta1
On Monday, 26 October 2020 at 07:14:55 UTC, Patrick Schluter wrote: You underestimate how spoiled windows developer are. Even these simple step are completely out of character for most software on the platform. 20 years ago it wasn't a problem, now on Windows 10 it's a whole other story. How many clicks to get the dialog to set PATH? On NT4 it was 2 clicks, now on Windows 10 I still haven't figured out how to do it without searching like a madman. To make it short. The Windows platform is getting more and more hostile to manual tuning. I use set PATH=%SystemRoot%\system32;%SystemRoot%
Re: mir-stat
On Tuesday, 13 October 2020 at 10:30:41 UTC, jmh530 wrote: The difference is that MIT says you can use it without restriction, including a few things, while Boost says you can do some things. I only meant that MIT license was more permissive in that if there are other things you want to do with it that are not listed on Boost (I don't know what that would be), then MIT would allow it. Just make sure you don't grant exclusive rights :)
Re: Visual D 1.1.0 released
On Thursday, 4 March 2021 at 13:42:47 UTC, Imperatorn wrote: https://filebin.net/19gupoeedfdjx5tx One GIF is the behaviour in C# I would like to have in D as well with static if, and the other is displaying typeid on hover. The second is a debug session. Visual Studio doesn't show type information in debug session for C# either, only variable name and value.
Re: Dr Callahan ports D compiler to OpenBSD
While we're at it, can I has SOCK_CLOEXEC and SOCK_NONBLOCK flags?
Re: D Language Foundation Monthly Meeting Summary
On Wednesday, 2 June 2021 at 14:02:29 UTC, Mike Parker wrote: On Wednesday, 2 June 2021 at 11:10:36 UTC, Dukc wrote: Phobos v2 is an official plan? That was news for me! Any chance to get a glimpse of what's planned for it? The overall goal is that it doesn't replace the current Phobos, but sits alongside it. Changed/improved/new functionality goes in the std.v2 namespace (or whatever it looks like in the end) and you can import that alongside existing std packages. I thought v2 is what it currently is, so the next would be v3.
Re: trash-d: Replacement for rm that uses the trash bin
On Tuesday, 24 August 2021 at 02:19:58 UTC, rushsteve1 wrote: https://github.com/rushsteve1/trash-d You marked all functions inline?
Re: D Language Foundation Quarterly Meeting, October 2021
On Friday, 5 November 2021 at 11:57:40 UTC, Mike Parker wrote: `-preview=in` will not be killed. It needs to be changed such that: * `in` always means `const scope ref`; the compiler will not attempt to pass by value based on platform-specific heuristics. What about C functions? The ABI changes.
Re: DIP1000: Memory Safety in a Modern System Programming Language Pt.1
On Wednesday, 22 June 2022 at 20:48:13 UTC, Steven Schveighoffer
wrote:
Sometimes algorithms require manipulation of structure, such as
sorting arrays, or using linked lists, and sometimes it's nice
to be able to point at things on the stack, temporarily. This
is one of the things I was looking forward to with dip1000,
since it does allow pointing at the stack when it can work out
the details.
This works:
```
struct S
{
int[] a;
int[] get() return scope @safe { return a; }
void set(return int[] b) return scope @safe
{ a=b; }
}
int[] f() @safe
{
int[2] a;
scope S t;
int[] b=t.get;
t.set=a;
return b; //no
}
```
Re: LDC 1.30.0
On Thursday, 21 July 2022 at 10:18:22 UTC, Christian Köstlin wrote: On a sidenote I am having problem downloading any 2.100.1 dmd version from dlang.org. A great moment, ldc is released before dmd :D
Re: Z80 Emulation Engine
On Tuesday, 22 April 2014 at 06:41:58 UTC, Manu via Digitalmars-d-announce wrote: But then you lose the incentive to return contribution back to the original community. I've worked in companies where we take OSS libraries, modified for our needs, and never offer the modifications back to the community. I've done it myself, and it's basically wrong. I am not aware of the license that encourages community contribution, but also doesn't infect your code like the plague? You said, it couldn't be commercialized. GPL prevents commercialization, if the latter won't happen anyway, GPL doesn't give you anything. I did that, but sent a patch to the developer, diff -ur doesn't hurt in the least. Though the tool is only used by developers, no redistribution required, so GPL wouldn't prevent from doing private changes and still benefit from them (the tool provided a very important feature absent in a commercial analog, and I added 3 more more cool features).
Re: Bounty for -minimal compiler flag
On Tuesday, 18 February 2014 at 02:24:32 UTC, Steven Schveighoffer wrote: Yes, and one can do it with a global flag too. The lack of this ability is really a terrible omission for D2. We have the flag - GCX.running, it's just not exposed.
Re: Tkd - Cross platform GUI toolkit based on Tcl/Tk
On Thursday, 8 May 2014 at 04:46:48 UTC, John wrote: How is the performance when compared to other GUIs like Qt or Gtk? For example, in one application, I need to dynamically create several hundred of controls at runtime. BTW, what's your use case? Nested tabbed dialog? After creation it should also resize fast, which can get problematic too.
Re: Tkd - Cross platform GUI toolkit based on Tcl/Tk
On Sunday, 4 May 2014 at 16:18:53 UTC, Gary Willoughby wrote: https://github.com/nomad-software/tkd https://github.com/nomad-software/tkd/blob/master/source/tkd/element/element.d Since you allocate CommandArgs in C heap, its content is invisible to GC and will be freed - uniqueData and callback.
Re: Tkd - Cross platform GUI toolkit based on Tcl/Tk
GC cleans up for you. Usually this won't happen because uniqueData is likely to be in data section and callback is likely to be a member of a widget used elsewhere. But if they aren't, GC will free them and you end up with dangling pointers in CommandArgs.
Re: DGui is alive
On Saturday, 24 May 2014 at 07:20:49 UTC, Denis Shelomovskij wrote: One can use `paint` event to draw image on button and there is `GridPanel` (with usage example `grid.d`) so I don't understand why `GridView` is needed and what is its purpose. Also I don't know what is `DataView` for. Haha, well, when people talk about GridView, they mean something like this: https://www.devexpress.com/Products/NET/Controls/WinForms/Grid/
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Wednesday, 28 May 2014 at 05:40:26 UTC, Jesse Phillips wrote:
When he explained why C++ inferred a const int type as int, he
tripped me up because D does drop const for value types.
Hmm, this bit me (doesn't compile):
void f(in char[] s)
{
auto s1=s;
s1=s;
}
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thursday, 29 May 2014 at 02:38:56 UTC, Jesse Phillips wrote: Hoping someone can confirm or deny this thought. int x2prime = void; // (at global scope) Since x2prime is module variable, I would expect that the compiler will always initialize this to 0 since there isn't really a performance hit. Or is using void guarantee it won't get initialized (so much value in that guarantee)? Depends on the implementation of tls, usually the .tls section is initialized data.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Friday, 30 May 2014 at 04:21:18 UTC, Jesse Phillips wrote: I've got two posts complete[1]. Since C++ and D are exactly the same for the majority of the code I'm only showing D and talk of C++'s choice. While the rules governing D's behavior are fairly simple I feel that I've expanded on the content enough to provide useful information beyond fixing C++'s problems. 1. http://he-the-great.livejournal.com/52333.html What do you mean "D does not provide a decltype"? typeof(cx) my_cx2 = cx;
Re: hap.random: a new random number library for D
Pass it by reference, I see no reason why MT can't be pure.
Re: hap.random: a new random number library for D
On Tuesday, 10 June 2014 at 10:57:32 UTC, bearophile wrote: Kagamin: Pass it by reference, I see no reason why MT can't be pure. I meant strongly pure :-) I'm afraid, this pure rng pattern precludes all pure optimizations, so it's effectively weakly pure.
Re: hap.random: a new random number library for D
On Tuesday, 10 June 2014 at 23:08:33 UTC, Chris Cain wrote: 4. I'd just like to say the idea of using ranges for seeds gets me giddy because I could totally see a range that queries https://random.org for true random bits to seed with, wrapped by a range that zeroes out the memory on popFront. Convenient and safe (possibly? Needs review before I get excited, obviously) for crypto purposes! In some scenarios impredictability is not enough. For example, when you generate a session id, an attacker doesn't have to predict it ahead of time, he can guess it at any time later. And if they listen to radio waves - that's an "open protocol", an attacker can setup antenna near their antenna and get the same readings. Cryptographic PRNG and quantum TRNG are better isolated, so it's harder to read them.
Re: Tkd - Cross platform GUI toolkit based on Tcl/Tk
BTW, there's some info about dragondrop in tk: http://wiki.tcl.tk/571
Re: Tkd - Cross platform GUI toolkit based on Tcl/Tk
On Thursday, 19 June 2014 at 19:24:15 UTC, SomeRiz wrote: Visual Studio like editor for TkD :/ Hmm... visual designers can usually build pixel-oriented GUI, tk uses layouts, which work with code a little better.
Re: Tkd - Cross platform GUI toolkit based on Tcl/Tk
On Friday, 20 June 2014 at 18:04:20 UTC, Nick Sabalausky wrote: While it's been awhile since I've used visual GUI designers much, I seem to remember them (at least the better ones anyway) being perfectly capable of doing resizable layouts. Any limitations seemed to have more to do with the widgets and GUI libs themselves rather than any inherent drawback to GUI designers in general. I seem to recall doing some resizable layouts even as far back as VB3. Anchors work, because they are simple and pixel-oriented. GTK boxes have too many settings to put them into a visual designer. Specialized non-pixel-oriented layouts do work with visual designers as they don't require configuration.
Re: Tkd - Cross platform GUI toolkit based on Tcl/Tk
On Monday, 23 June 2014 at 08:10:49 UTC, Jacob Carlborg wrote: Yes, correct. Why do you need 64bit? All 64bit Windows computers can run 32bit applications. High memory requirements :( If you have performance problems with a (big) database, a possible solution is to cache data on the client.
Re: Tkd - Cross platform GUI toolkit based on Tcl/Tk
On Monday, 23 June 2014 at 08:10:49 UTC, Jacob Carlborg wrote: Yes, correct. Why do you need 64bit? All 64bit Windows computers can run 32bit applications. Also big grids; hundreds of thousands items.
Re: EMSI has a Github page
https://github.com/economicmodeling/containers/blob/master/src/containers/dynamicarray.d#L72 Does this work? You try to remove new range instead of old one. Also you should remove old range only after you added new range, so that GC won't catch you in the middle.
Re: EMSI has a Github page
And then it will still be able to catch you between realloc and addRange.
Re: DConf 2014: Adam D Ruppe's amazing slideless talk on x86 Bare Metal and Custom Runtime Programming
On Saturday, 19 July 2014 at 03:31:57 UTC, Adam D. Ruppe wrote: Plain text transcript of the video (typed up by me, so there may be some errors but the bulk of it should be readable) http://arsdnet.net/dconf-transcript.txt Hmm... you're trying to implement a lot of features. I don't use typeinfos, and I got a lot working: IO, crypto, allocators, string switch, assert handlers. My minimal program is 5632 bytes (119 LOC) - reestablishes PPPoE connection when computer goes out of sleep. Another is 1k LOC authentication service (runtime 127 LOC) and compiles to 23 KB.
Re: Cassowary.d
On Sunday, 27 July 2014 at 12:01:47 UTC, Yuriy wrote: On Sunday, 27 July 2014 at 11:44:35 UTC, ketmar wrote: preliminary, but working port of Cassowary Solver — GUI-oriented constraint solver, toolkit-agnostic layout engine. it's not D-spirited yet, but it works. todo list includes templated classes and bindings for gtk.d. feel free to fork and improve. url: http://repo.or.cz/w/cassowary.d.git +1 http://code.dlang.org/packages/cassowary-d http://code.dlang.org/?sort=updated&category=library.scientific.linalg categorization can be better though.
Re: DMD v2.066.0-rc1
On Wednesday, 6 August 2014 at 16:19:39 UTC, Brad Anderson wrote: I don't think it's difficult for them, I think they often just don't know they can. Environment variables just aren't as well known on Windows these days. If you are an 18 year old getting into programming you likely have never even heard of environment variables or batch files and may not even know how to use the command prompt (or open it for that matter). Windows Vista came out when they were 10 years old and the days of having to know and use the command prompt for typical users were long gone by this point. I'm thirty so I knew and used MS-DOS as a kid (I had to) but if you've never used these things how would you know you could? There are OS courses at institutes, where you have linux, gcc and learn, how pipes, shared memory and synchronization mechanisms work.
Re: Fix #2529: explicit protection package #3651
On Tuesday, 19 August 2014 at 17:11:19 UTC, Dicebot wrote:
Any specific ideas? I can't imagine any clean solution - and
proposed language extensions fits naturally into existing
system without introducing any new concepts. It is also
somewhat frequently asked about in NG.
---
module std.internal.mod1;
package(std) void foo() {}
module std.mod2;
import std.internal.mod2;
void bar() { foo(); }
---
Isn't it equivalent to
---
module std.internal_mod1;
package void foo() {}
module std.mod2;
import std.internal_mod1;
void bar() { foo(); }
---
Re: D 2.066 is out. Enjoy!
On Monday, 18 August 2014 at 23:07:27 UTC, ketmar via Digitalmars-d-announce wrote: i myself using dmd-git-head and heavily ;-) patched gdc, but when i tried to convince my co-workers to use D, they looked at the page with releases first. not feature list or some comparisons. neither to "buglist". "as this is relatively young language, it must have frequent releases with bugfixes and new features!" they tolerate some regressions in some releases, but they want to see that releases. don't ask me why they thinking like this. i don't know. but it's the fact. Can't it be addressed by publishing release schedule, like llvm does it, to indicate the work is going on?
Re: Fix #2529: explicit protection package #3651
On Wednesday, 20 August 2014 at 07:47:36 UTC, ketmar via Digitalmars-d-announce wrote: but it requires to dump all 'subpackages' into one flat directory and with ugly names. Huh? If std.datetime and std.regex are subpackages of `std` package, it usually means, they should reside in `std` directory, no? And how explicit package protection can change that?
Re: Fix #2529: explicit protection package #3651
On Wednesday, 20 August 2014 at 13:05:54 UTC, Dicebot wrote: Your proposal makes such module layout illegal: std.package1.module1 std.package1.module2 std.package1.subpackage.module1 std.package1.subpackage.module2 (can't have symbols in subpackage that are also available to package1 but not whole std / public, must have `subpackage_module1` instead, `package_1_subpackage_module1` if it must be available for whole std) If some utility is internal to std.package1 an used in the entire std.package1, shouldn't it sit in std.package1? Why push it to subpackage? std.package1.module1 std.package1.module2 std.package1.internal <- package1's internals go here std.package1.subpackage.module1 std.package1.subpackage.module2
Re: Fix #2529: explicit protection package #3651
On Wednesday, 20 August 2014 at 09:40:37 UTC, ketmar via Digitalmars-d-announce wrote: imagine mybiglib, mybiglib.internal, mybiglib.other, and each of them not single module, but package itself. so we have module mybiglib.other.thingy which wants to use functions from module mybiglib.internal.wisdom, which is part of mybiglib.internal package. Do we need a hierarchy of internals, is the problem this big? Why mybiglib.wisdom is not good?
Re: Fix #2529: explicit protection package #3651
On Wednesday, 20 August 2014 at 14:33:53 UTC, Kagamin wrote: On Wednesday, 20 August 2014 at 09:40:37 UTC, ketmar via Digitalmars-d-announce wrote: imagine mybiglib, mybiglib.internal, mybiglib.other, and each of them not single module, but package itself. so we have module mybiglib.other.thingy which wants to use functions from module mybiglib.internal.wisdom, which is part of mybiglib.internal package. Do we need a hierarchy of internals, is the problem this big? Why mybiglib.wisdom is not good? As I see on the realistic example of datetime, which is BIG, we only need to split it into a flat set of files without an overly deep package hierarchy.
Re: Fix #2529: explicit protection package #3651
On Wednesday, 20 August 2014 at 14:35:31 UTC, Dicebot wrote: It may semantically belong to subpackage but still needs to be available to package1, something not uncommon in templated code (subpackage is generic implementation, package1 is specialization that still needs access to non-public functions). If generic implementation is designed to be customized, it probably means, it should be widely available for customization, like xml document and base64 encoder. Also it's probably a logical error if base type is less visible than the derived type. What you propose is effectively prohibiting to use packages to organize your code and requiring to design your module hierarchy based on desired protection relations, not other way around. I think it is conceptually wrong approach and unnecessarily restrictive compared to overall D design principles (no single "true" way of doing things) It's ok for packages to exchange public interface, but internals? If a subpackage has internals, they are for its usage, and consumable functionality should be provided through public interface.
Re: D 2.066 is out. Enjoy!
On Wednesday, 20 August 2014 at 16:25:04 UTC, disapointed user wrote: too bad that i wasted my time for such a long time. i post a link to that thread with your answer to everywhere i can, so that others won't waste their time too. anyway good luck in the future for you linux guys. Well, people have different perspectives :) see http://forum.dlang.org/post/lrsnjovurigezboqx...@forum.dlang.org
Re: D 2.066 is out. Enjoy!
On Friday, 22 August 2014 at 08:18:18 UTC, Daniel Murphy wrote: 2. These features are rather difficult to use, and I don't want people to think they can just plug-and-play. I've spent a lot of time fighting compiler alignment bugs, which are their own special kind of hell. Many of those issues have been resolved now, but only in the areas that ddmd actually exercises. Do you suggest that C++ interfaces should be written by the compiler team?
Re: Fix #2529: explicit protection package #3651
On Friday, 22 August 2014 at 15:06:14 UTC, Dmitry Olshansky wrote: Example structure: mod/package.d mod/internal/bar.d mod/... I actually face it in Phobos right now, my blocked pull: https://github.com/D-Programming-Language/phobos/pull/2412 I think, it should have structure std.regex.package; std.regex.backtracking; std.regex.ir; What is the reason to have regex stuff in a remote directory? That would make things hard to find and navigate.
Re: Fix #2529: explicit protection package #3651
On Wednesday, 20 August 2014 at 14:40:34 UTC, Dicebot wrote: On Wednesday, 20 August 2014 at 14:36:59 UTC, Kagamin wrote: As I see on the realistic example of datetime, which is BIG, we only need to split it into a flat set of files without an overly deep package hierarchy. We _may_ split it into flat set files (solving only part of the problem) but it is desirable to have a deeper package hierarchy. Package hierarchy is not just an encapsulation tool, it is also a great way to simplify navigation and finding needed modules - something that Phobos is current terrible at exactly because of flat hierarchies. What is difficult to find? With flat structure you have all files right before your eyes. If you need std.datetime.systime module, you open std/datetime/systime.d file - that's the reason of needlessly restricting code structure with modules as if one size fits all.
Re: Fix #2529: explicit protection package #3651
On Wednesday, 20 August 2014 at 14:40:34 UTC, Dicebot wrote: On Wednesday, 20 August 2014 at 14:36:59 UTC, Kagamin wrote: As I see on the realistic example of datetime, which is BIG, we only need to split it into a flat set of files without an overly deep package hierarchy. We _may_ split it into flat set files (solving only part of the problem) but it is desirable to have a deeper package hierarchy. Package hierarchy is not just an encapsulation tool, it is also a great way to simplify navigation and finding needed modules - something that Phobos is current terrible at exactly because of flat hierarchies. And with an excessively deep folder structure it will be much more tedious to walk the whole thing. It's deep nesting, which will make things hard to find.
Re: Fix #2529: explicit protection package #3651
On Wednesday, 20 August 2014 at 20:39:06 UTC, Chris Nicholson-Sauls wrote: module foo.bar.one; module foo.bar.internals; // package-protected utilities module foo.bar.subpkg.two; module foo.bar.subpkg.internals; // package-protected utilities and module 'two' cannot access the 'bar' utilities. Really? Looks like a bug. You'd better check if it's intended to work that way. This is needlessly limiting, forcing design choices that should not be dictated by the ability/inability to separate public and private API. It also precludes many valid and good uses of nested package.d modules. If some thing is used in entire foo.bar package, then it's foo.bar's internal, not foo.bar.subpkg's internal. I think, it's natural when the wider the thing is used, the higher in hierarchy it sits. I really don't see any equally strong counter-argument. But then, I've wanted this exact fix for literally years now. I don't really see, what it blocks. It also is not limited to internal utility modules. It can be useful for systems that select at compile time from one of a number of system-specific implementations of a given interface/api. It can be useful for granting privileged access to certain api's and/or resources to specific module(s). An example being: grant access to unsafe but versitile data manipulators solely to the subpackage containing the loaders. If those manipulators are used solely in loaders subpackage, they should belong to that package. Though I don't really see a problem here: there was an implementation of xml document, which allowed unsafe (but fast) specialization, which was believed to be useful for public usage. It fits well into D philosophy that safe things should be available by default and unsafe/fast things should be possible.
Re: Fix #2529: explicit protection package #3651
On Wednesday, 20 August 2014 at 14:44:21 UTC, Rory McGuire via Digitalmars-d-announce wrote: On Wed, Aug 20, 2014 at 4:33 PM, Kagamin via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: Do we need a hierarchy of internals, is the problem this big? Why mybiglib.wisdom is not good? It gets really unwieldy when you want to put a whole bunch of things into one project and give control of different packages to different teams. Yes you could use multiple libraries in a lot of cases but if you're wanting it in a single setup / package (like phobos), especially one that is internal to another package you need sub-packages. Yes, public interfaces of packages can form a hierarchy (which still shouldn't be more complex than necessary), but internals? Examples that would use this are: - kitchen sink libraries like phobos I proposed an example of datetime module, that I don't see a problem with internals there. Can you point to an exact line in source, which suffers from this?
Re: Fix #2529: explicit protection package #3651
On Saturday, 23 August 2014 at 09:14:13 UTC, Dmitry Olshansky wrote: Yes, that was my initial pull. The stuff inside was marked as `package`, as only package.d currently has the same public API. Then Dicebot suggested that since all modules are for the moment internal they have to be moved somewhere until public API is fleshed out (as it may change module name etc.). 2 options that both do NOT currently work: std.regex.internal std.internal.regex If the user relies that a symbol is found in std.internal.regex.backtracking, moving it will break the code too. So what's the difference?
Re: Fix #2529: explicit protection package #3651
On Saturday, 23 August 2014 at 09:24:04 UTC, Jacob Carlborg wrote: A symbol declared "package" can only be accessed within its own package. It cannot be accessed from sub packages or super packages. I didn't know about that. Should it really work that way?
Re: Fix #2529: explicit protection package #3651
On Saturday, 23 August 2014 at 10:04:40 UTC, Dmitry Olshansky wrote: For what its worth I'd _prefer_ std.regex.internal as in my opinion internals got to be well contained. But as discussed, `package` doesn't work this way. It can be a philosophical matter, but in my experience grouping by functionality is genuine, and access is an afterthought, so grouping by access doesn't work in the long term, as code naturally (spontaneously) groups by functionality. The reason is when you maintain code, you traverse it according to functionality, because you work with implementation, and protection is interface, so protection is ignored. If you add a public functionality to internal module (ranges often end up like that), you can either just qualify it with public access, as it's done in normal modules, or refactor and move it to public module, so you end up with logically grouped functionality separated between two or more modules, which try to enforce grouping by access, while in normal modules you have logically grouped functionality in the same module even if they have different access. Also you can end up with public functionality in internal module, if the member proved to be stable, robust and use case for it arises.
Re: Fix #2529: explicit protection package #3651
On Saturday, 23 August 2014 at 11:04:35 UTC, Jacob Carlborg wrote: That's what we're trying to fix with this change. The proposal is to make internals visible to super packages, I only wonder whether internals visible to some package should be hidden from its subpackages.
Re: D for the Win
On Sunday, 24 August 2014 at 09:24:55 UTC, Jacob Carlborg wrote: The numbers in the benchmark has just been updated. DMD is behind C. GDC is the fastest of all and LDC is ahead of Clang but behind GCC. Seems pretty good to me. D and C versions use different random number generators.
Re: Fix #2529: explicit protection package #3651
On Sunday, 24 August 2014 at 02:22:41 UTC, Dicebot wrote: Well difference is that "internal" substring in the fully qualified name that is much more likely to tell user he is better to not touch it. However, original Kagamin proposal of embedding it into module names themselves does address that if you are ok with resulting uglyness. Both ways it's a convention, and I don't see, why such convention should exist in the first place, member protection has nothing to do with module name, which reflects module's functionality. On Sunday, 24 August 2014 at 02:34:01 UTC, Dicebot wrote: It can be a philosophical matter, but in my experience grouping by functionality is genuine, and access is an afterthought, so grouping by access doesn't work in the long term, as code naturally (spontaneously) groups by functionality. That does contradict your statement that any stuff used in parent packages must go to up the hierarchy which is exactly grouping by access :) Access there means protection, usage reflects functionality. I can probably give a more practical example I have just recently encountered when re-designing one of our internal library packages. It was a "serialization" package and sub-packages defined different (de)serialization models, some of those defining special wrapper types for resulting data that enforce certain semantics specific to that serialization model via the type system. It is not surprising that most internal details of such wrappers were kept package protected as exposing those to user could have easily violated all assumptions (but was needed to implement (de)serialization efficiently). It has become more complicated when "meta-serializers" have been added to parent package - templated stuff that took any of sub-package implementations and added some functionality (like versioning support) on top. Being generic thing it reside in higher level "serialization" package but to be implemented efficiently it needs access to those internal wrapper fields. Moving wrapper modules to parent package is not an option here because those are closely related to specific serialization model. Exposing stuff as public is not an option because anyone not deeply familiar with package implementation can easily break all type system guarantees that way. Moving "meta-serializers" to sub-packages is quite a code duplication. Right now I keep that stuff public and say in docs "please don't use this" which is hardly a good solution. 1. Making wrapper protected will preclude writing new serializer. 2. Using wrapper methods can be meaningless without serializer. 3. Serializer may just not expose wrapper, then user will have no way to access it. 4. .net has quite a lot of things like http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.configuredtaskawaitable%28v=vs.110%29.aspx and nothing explodes even though .net programmers are believed to be really stupid and evil. It's a virtue of Stackoverflow Driven Development. On Sunday, 24 August 2014 at 02:39:40 UTC, Dicebot wrote: On Saturday, 23 August 2014 at 09:00:30 UTC, Kagamin wrote: What is difficult to find? With flat structure you have all files right before your eyes. If you need std.datetime.systime module, you open std/datetime/systime.d file - that's the reason of needlessly restricting code structure with modules as if one size fits all. It is the same reasoning as with deep filesystem hierarchies and, well, any data hierarchies - once the element (module / file) count becomes bigger than ~dozen you only really notice things you know to look for. Contrary to that deeply nested categorized hierarchies are easy to casually to search through if you don't know exact module name - just iteratively pick whatever package fits the theme until you find what you want. I'm afraid, hierarchies make things harder to find. If you don't know what is where, flat organization will present you with everything readily available right before your eyes. With deep hierarchy you're left with abstract or poorly chosen categories at every hierarchy level, so effectively you have to walk the entire hierarchy, which is much more tedious than scroll a flat list of modules viewing ten modules per scroll. Badly named list of modules (like what we have now in phobos) scales well up to 100, well-named list is much more manageable: if you need xml, you already know it's near the end of the list - it's easy to find even among 1000 files - you don't ever need to scroll entire list. If it's not there, where do you go? There's no obvious answer. So even shallow hierarchy is more troublesome than a flat list of 1000 modules. I don't believe hierarchy will magically solve navigation problems just because it has folders. I remember coding a bit in C#/.NET platform ages ago - it was totally possible to find relevant modules without even looking in docs, just using auto-complete through suggeste
Re: 438-byte "Hello, world" Win32 EXE in D
On Monday, 8 September 2014 at 07:01:19 UTC, Andrej Mitrovic via Digitalmars-d-announce wrote: I guess this is great news for virus writers. :P Why? Modern viruses are bloatware: https://www.virustotal.com/en/file/73559b15d1f55a9f08a5674fd4320a7ba9ff4e98f0949a1b2a756ec8eafd5caf/analysis/
Re: 438-byte "Hello, world" Win32 EXE in D
On Monday, 8 September 2014 at 07:59:37 UTC, Ola Fosheim Grøstad wrote: «Smallest PE file that downloads a file over WebDAV and executes it: 133 bytes» http://www.phreedom.org/research/tinype/ But that downloaded file is bloatware, because it has to implement functionality, which is not provided by the system. That tiny pe file doesn't download anything, it's completely done by the system.
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Wednesday, 1 October 2014 at 14:29:16 UTC, Paulo Pinto wrote: You would be surprised how some Fortune 500 companies are doing their serious work in 100% Windows servers. Sadly I need to comply with NDAs. Isn't NASDAQ enough?
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Wednesday, 1 October 2014 at 05:09:45 UTC, Nick Sabalausky wrote: Apparently bash has it's own "heartbleed" now, dubbed "shellshock". Does it affect dash? Also, how does one update software on linux? Last I checked, when new version is out, repository of the previous version becomes utterly abandoned. A pity, on windows one can roll new software versions as long as they are maintained.
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Wednesday, 1 October 2014 at 15:45:26 UTC, eles wrote: The first thing that I love in Linux is the centralized update. The downside is it's taken down centrally too, while distributed windows software continues to work independently of each other. On Wednesday, 1 October 2014 at 15:48:58 UTC, Dicebot wrote: This claim is so strange I can't even understand what it is about. Which repositories get abandoned? Repositories of the not latest version of the OS. Because only latest version receives development. That is, if the OS doesn't have rolling updates.
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Wednesday, 1 October 2014 at 17:07:53 UTC, eles wrote: For how long will the repository taken down? 24 hours? 3 days? As long as nobody works on it, i.e. forever. You speak about Red Hat or Debian or Ubuntu repositories? And? You cannot live without the super-updates for 3 days? The problem that you expose is negligible. I don't update software without a reason. Only when something bugs me. Most of them, have. And for the release-style distributions, upgrade is rather straightforward A have linux mint 12 installation with mint4win (wubi), on linux mint forums I was told, that updating from the latest repository won't work. I would be grateful, if you explain, how to upgrade it to the latest version. Yeah, theoretically it should be able to just overwrite files on disk without paying much attention to disk nature.
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Wednesday, 1 October 2014 at 20:03:11 UTC, Dicebot wrote: This a very unpleasant experience you get compared to sticking to LTS or up to date distro Erm, upgrading to the latest version is exactly what I want, old version is of no interest to me. I read, one can reorient aptitude to latest repository and update everything, but I was told it won't work. So the question is how to update kernel and everything else?
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Thursday, 2 October 2014 at 07:14:35 UTC, Iain Buclaw via Digitalmars-d-announce wrote: Doesn't Linux Mint provide an upgrade facility for you? No idea. Upgrading by using apt is doable, but from what you've demonstrated about your knowledge, I wouldn't recommend it to you. How software's operation depends on me?
Re: [OT Security PSA] Shellshock: Update your bash, now!
How software's operation depends on me? Ah, ok, I see the explanation in tutorial.
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Thursday, 2 October 2014 at 07:43:54 UTC, eles wrote: update-manager -d It works. Does it perform package upgrade? The comments are rather scary: --- Hi, I have installed Linux mint 15 with Mint4Win as Dual boot with Windows 7. Then upgraded it to Mint 16 and it was running fine. But when I upgrade to Mint 17 (Qiana), after restarting the partition loop0 (or loopback0 or something like that) fails to load. It shows an error like, Press I to ignore, S to skip or M for manual recovery. Please tell me a way to fix this. Or let me know if it is not possible. --- Looks like my case. Are fstab and mtab replaced during upgrade?
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Thursday, 2 October 2014 at 11:40:31 UTC, eles wrote: You simply made the wrong choice in the beginning. Well, it looked popular and easy. Can I upgrade my mint to lmde?
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Thursday, 2 October 2014 at 12:44:08 UTC, eles wrote: I doubt. At least, not easily. However, installing LMDE should be a one-time process (it's a rolling distribution). Do rolling distributions guarantee to not overwrite fstab? How mint package update differs from a rolling distro package update?
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Friday, 3 October 2014 at 11:25:59 UTC, eles wrote: Debian and Debian-based asks you to confirm file overwrite (usually, the diff is displayed too). Isn't it the same package manager? It should be able to do the same on mint. Or may be fstab can be copied somewhere and then back at some point? On Sunday, 5 October 2014 at 08:54:46 UTC, eles wrote: Linux Mint, starting from version 17, marks a departure from previous releases (this is why you migh have encountered difficulties in upgrading) by keeping the same code base (Ubuntu 14.04 LTS) for the next 5 years. So, during this time, it will basically be a rolling-distribution, as some software will get updated just as regular (security fixes etc.) happens. Truly rolling or only security updates? Well, I'm ok with a fresh install. But can it run under the target linux itself? Or rather what to run from the disk? Since mint4win installation is a virtual disk, I'm not sure the installer will find it gracefully, they're usually partition-oriented. Not sure if this eliminates problem with fstab though.
Re: D2 port of Sociomantic CDGC available for early experiments
On Tuesday, 7 October 2014 at 20:06:43 UTC, Walter Bright wrote: On 10/6/2014 9:51 AM, Dicebot wrote: https://github.com/D-Programming-Language/druntime/pull/985 Thank you. This is great progress! I understand the caveats, but can this be put into a shape where it can be pulled despite being a work in progress? I.e. have the code be disabled by default? That will help encourage the community to help out with the gaps. BTW, why not dub package? GC is pluggable, so can be shipped as a 3rd-party library.
Re: D2 port of Sociomantic CDGC available for early experiments
On Friday, 17 October 2014 at 17:53:18 UTC, Andrej Mitrovic via Digitalmars-d-announce wrote: I've come to even hate anything GUI (except maybe the editor), I'd hate to even think about browsing the file system with a mouse anymore. Yes, you can: Windows Explorer does support keyboard input :)
Re: Endovena: a dependency injection framework.
Unity uses UnityContainer. So there can be a discriminator in the name.
Re: D2 port of Sociomantic CDGC available for early experiments
On Thursday, 23 October 2014 at 08:46:46 UTC, Dicebot wrote: Currently druntime is packaged as part of Phobos library binary so I don't see easy way to do it. It could be possible to do the replacement at the startup using GC Proxy instrastructure but CDGC does not currently support it (though it is not complicated to do). The idea is that you specify CDGC dub package a dependency for your application and dub links your application with it, so you end up with CDGC in your application.
Re: D2 port of Sociomantic CDGC available for early experiments
On Thursday, 23 October 2014 at 09:57:38 UTC, Dicebot wrote: Uh, what will it link to? extern(C) function like gc_malloc? druntime links to those statically itself so you will get application that links to different GC than druntime itself. The reason is CDGC provides symbols like gc_malloc and after that the linker has no reason to pull default GC from the library: it doesn't pull what's not necessary.
Re: D2 port of Sociomantic CDGC available for early experiments
On Thursday, 23 October 2014 at 13:13:06 UTC, Mathias LANG wrote: It will clash at best, or just ignore cdgc, as objects are considered as a whole, in link order. At best, they won't clash :) If the default GC is not pulled by the linker, why should they clash? Now, if druntime defines gc_alloc, it won't link. You have to extract all conflicting symbols out of druntime. Do you consider possibility of breaking changes as a blocker for feasibility of 3rd-party libraries?
Re: D2 port of Sociomantic CDGC available for early experiments
On Thursday, 23 October 2014 at 15:53:19 UTC, Sean Kelly wrote: We could experiment with separately linking the GC. It wouldn't be hard to do, though the link line might be a bit weird, since core, rt, and gc are all interdependent in terms of link dependencies. Can't it work like any other user library?
Re: D2 port of Sociomantic CDGC available for early experiments
This means, the program should link with object file instead of a library. Alternatively it can be pulled eagerly by the proposed `init` function if it will explicitly depend on a symbol from a gc library - the linker could resolve the symbol early.
Re: Endovena: a dependency injection framework.
Usually an object receives all needed dependencies with the constructor and thus doesn't need the container itself. Well, either way, it's better to pass one object around instead of ~10 or more.
Re: Devisualization and DWC
On Friday, 7 November 2014 at 10:48:46 UTC, Rikki Cattermole wrote: - Native GUI controls (such as the menu for OSX) D native or OS native?
Re: gchunt v0.1.0 is out!
https://github.com/D-Programming-Language/phobos/blob/271c771a57764dcc511ca12ae91d490872d9b500/std/base64.d#L1144 Probably should be an assert?
Re: gchunt v0.1.0 is out!
Hmm... now that I think of it, base64 is a format used for data transfer, so it's unlikely to come from a trusted source.
Re: DCD v0.4.0
BTW, does DCD differentiate between function overloads? Semantic analysis would be needed to do it. How much of it DCD implements?
Re: D is for Data Science
On Tuesday, 25 November 2014 at 01:10:56 UTC, Walter Bright wrote: I know it's a tough call. But I do see these sorts of comments regularly, and it is a fact that there are too many D libraries gone to seed that won't compile anymore, and that makes us look bad. Or this: https://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/cmbssac It was the endless std.logger bikeshedding that finally did me in. Even if they get it into std.experimental in the next release, I'm finally done. I cancelled my projects and pulled them off dub. Is this a much better reason?
Re: forum.dlang.org is now using DCaptcha
On Wednesday, 3 December 2014 at 00:56:12 UTC, Brad Anderson
wrote:
Maybe make the ones on d.learn extremely simple.
---
What does the follow program print?
void main()
{
import std.stdio : writeln;
writeln("foo");
}
---
No algorithms, no math. Just extremely basic stuff. Nobody, not
even our weirdly efficient resident furniture spam bot is going
to take the time to write a bot to answer a question like that.
Bots don't write bots, lol.
I think, a little math doesn't hurt.
void main()
{
int a, b=2;
a++;
a = a+b+1;
writeln("foo",a);
}
Re: forum.dlang.org is now using DCaptcha
On Thursday, 4 December 2014 at 02:29:39 UTC, Faux Amis wrote: This has to be a joke! I couldn't answer a single question: What is the name of the D language syntax feature illustrated in the following fragment of D code? string a = x"5095 f9 95d723c2"; Seems like hex to me What is the name of the D language syntax feature illustrated in the following fragment of D code? /+ t = w * g; /+ t = 47; +/ +/ Those look like comments to me The test doesn't differentiate between human and robot. It tries to differentiate between human wanting to learn D and one not wanting.
Re: C# to D Compiler :)
On Friday, 19 December 2014 at 08:11:42 UTC, Ronald Adonyo wrote: Done, does anyone have a good idea of how to write Async/Await using fibers or state machines in D ? Same as in .net, look at the generated IL, an async method should return a chain of tasks.
Re: 2D game engine written in D is in progress
On Friday, 19 December 2014 at 17:21:43 UTC, ketmar via Digitalmars-d-announce wrote: have, as i still got the closed proprietary system. what google really has with their "open-sourceness" is a bunch of people that works as additional coders and testers for free. Well, those people want to do that, so why not?
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 23 December 2014 at 07:18:01 UTC, Dicebot wrote: Project itself is very cool but I am in doubts about possibility of merging this upstream. Doing so would make full D implementation effectively impossible without some C++ compiler already available as a library on same platform - quite a restriction! Why C++? Any language can be plugged in. On Tuesday, 23 December 2014 at 11:53:38 UTC, Dicebot wrote: Consider both things like embedded/MIPS and Windows64 - LLVM tooling is not as strong on those right now Win64 is nearing completion. LDC can compile and run code for quite some time already. provide such easy way to reuse C++ frontend and with DMD/MSVC it is simply beyond feasibility. AFAIK, clang features MSVC compatibility. By upstream I don't mean LDC upstream but D upstream - we don't want it to become part of full language spec if implementation is so reliable on specific toolchain. Another reason is to ease integration with C++. Language plugin is an obvious solution.
Re: Calypso: Direct and full interfacing to C++
On Monday, 22 December 2014 at 23:14:44 UTC, Elie Morisse wrote: • Structs https://github.com/Syniurge/Calypso/blob/master/tests/calypso/showcase.d testClass cls = new testInherit; This should be written testClass* cls = new testInherit; In C++ struct and class differ only in symbol mangling. They are both value types, support inheritance, copy constructors etc. By looking at the declaration you can't decide if a class should be used as value type or reference type, so better treat it as value type like in C++.
Re: Calypso: Direct and full interfacing to C++
Or it can switch depending on preprocessor definitions:
---
class WXDLLIMPEXP_BASE wxString
#ifdef wxNEEDS_WXSTRING_PRINTF_MIXIN
: public wxStringPrintfMixin
#endif
{
---
Re: Calypso: Direct and full interfacing to C++
On Monday, 9 February 2015 at 04:33:04 UTC, Kelly wrote: Ugh, this forum needs a preview button!! Sorry about the poor formatting, Kelly http://pastebin.com/
Re: Calypso: Direct and full interfacing to C++
http://forum.dlang.org/post/mbqt88$a6n$1...@digitalmars.com looks like C++ class support is shifting to value types.
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 17 February 2015 at 02:16:58 UTC, Kelly wrote: P.S. I HATE THIS FORUM EDITORplease add a preview button, whoever takes care of this!?!? I take notes in a different editor and then paste here and it looks fine, only to end up mangled when actually submitted...ugh :) You mean wrapping? Don't wrap the text manually, server does on its own.
Re: Packt is looking for someone to author a "Learning D"
On Sunday, 15 February 2015 at 04:38:08 UTC, Craig Dillabaugh wrote: Just my personal opinion as one who recently finished a 200 page thesis in Latex, and is now working for a company where we do all our internal documents in Word. Latex certainly has its ugly warts, but it is so nice for lengthy document1. Isn't latex for document restyling? What you would use it for? There's little time to only write the text, let alone fiddling with styles and typesetting. Word is better in this sense that it gets the end result just by saving the document.
Re: Packt is looking for someone to author a "Learning D"
Well, Word can diff and merge documents, though, it works with sharepoint, not vcs.
Re: let (x,y) = ...
On Thursday, 19 February 2015 at 09:50:25 UTC, bearophile wrote: I prefer "let", it's much more traditional and descriptive. C++ standard library is often a bad example to follow... Doesn't "let" normally declare a new variable?
