Re: D Language Foundation June 2022 Monthly Meeting Summary
I wrote up a thing in my blog about what I'd like to see from dips and the steering of the language and there might be some overlap with your vision document concepts: http://dpldocs.info/this-week-in-d/Blog.Posted_2022_06_20.html
Re: Window created with Windows API is not visible
On Saturday, 18 June 2022 at 23:00:36 UTC, solidstate1991 wrote: This is going to be a long match. you might consider using another exisitng lib. my simpledisplay.d does all this and much more for example
Re: Comparing Exceptions and Errors
On Saturday, 4 June 2022 at 22:31:38 UTC, Ola Fosheim Grøstad wrote: So what do you have to do to avoid having Errors thrown? How do you make your task/handler fault tolerant in 100% @safe code? Run it in a separate process with minimum shared memory.
Re: What happened to Deimos and why ?
On Saturday, 4 June 2022 at 13:44:06 UTC, Alain De Vos wrote: What happened to Deimos and why ? Nothing, it does its job same as it always has.
Re: How to fix "typesafe variadic function parameter"?
On Tuesday, 24 May 2022 at 22:46:55 UTC, Andrey Zherikov wrote: return S(s); return S(s.dup); The variadic lives in a temporary array that expires at the end of the function. So copying it out to the GC lets it live on. Your code was wrong on 2.099 too, but the compiler didn't tell you.
Re: Cannot check function address
On Tuesday, 24 May 2022 at 18:54:33 UTC, frame wrote: Usually that works fine as shown in module A but for some reason not in module B. Do you have some other definition of fun somewhere?
Re: How to call destroy() in @nogc?
On Tuesday, 24 May 2022 at 14:11:57 UTC, Steven Schveighoffer wrote: Note it has no idea what the real object type is at this point, just that it is an Object (which does not have a @nogc destructor). It actually has nothing to do with Object. It doesn't have a destructor at all, so there's no problem calling it from any context. The real problem is that destructors don't actually use the virtual machinery and call super(), meaning it is impossible to tell at compile time what they're doing at all. I know I wrote at length about this somewhere but can't find it right now. Probably in the chatroom. But even if you know static type, you can't make assumptions about the dynamic type since destructors (for no good reason tbh) don't follow the same rules as other virtual methods, despite the spec saying they are virtual.
Re: Error: undefined symbol: _WinMain@16 When try compile no console
On Thursday, 19 May 2022 at 21:41:50 UTC, Marcone wrote: Are you using the `-L/entry:mainCRTStartup` or the `L/entry:wmainCRTStartup` ? -L/entry:mainCRTStartup try the w one too. both doing the same result?
Re: Release: serverino - please destroy it.
On Monday, 9 May 2022 at 19:20:27 UTC, Andrea Fontana wrote: Thank you. Looking forward to getting feedback, bug reports and help :) BTW I'm curious, what made you not want to use my cgi.d which has similar capabilities?
Re: Release: serverino - please destroy it.
On Sunday, 8 May 2022 at 22:09:37 UTC, Ali Çehreli wrote: That effectively uses multiple GCs. I always suspected that approach would provide better latency. My cgi.d has used some fork approaches for a very long time since it is a very simple way to spread this out, it works quite well.
Re: GCC 12.1 Released (D v2.100-rc.1)
On Saturday, 7 May 2022 at 22:07:58 UTC, Iain Buclaw wrote: I expect it only to increase as more of the old opaque compiler-library interface is replaced with a templated interface that exposes the guts of what each helper does (for improved run-time performance, of course). Well, I'm pretty sure if we do this carefully we can have the best of both worlds. It is just important to get the interface right at this stage, then we can look at the other optimizations later with precompiling and such.
Re: Library for image editing and text insertion
On Tuesday, 26 April 2022 at 18:31:49 UTC, H. S. Teoh wrote:
maybe look at Adam Ruppe's arsd library
(https://github.com/adamdruppe/arsd) for some lightweight
modules that read common image formats and do some primitive
image manipulations.
I don't actually have an image to image blit function, but
writing one is trivial - just loop over it and call alphaBlend.
It can load ttf fonts, render them to bitmaps, load images,
combined them, then save images. Can even load ttfs off the
operating system if you wanted to use those or even have the
OS functions do the drawing instead of diy, but probably easier
to diy this simple case.
Sample code would be:
---
import arsd.image;
import arsd.ttf;
void main() {
auto image = loadImageFromFile("/home/me/small-clouds.png");
if(image is null)
throw new Exception("Couldn't load the image file");
auto tci = image.getAsTrueColorImage(); // convert to rgba for
simplicity
import std.file;
auto font = TtfFont(cast(ubyte[])
std.file.read("/home/me/arsd/sans-serif.ttf"));
int width, height;
auto bitmap = font.renderString("Hello", 14, width, height); //
it populates width and height fyi
// where we want to put it
int xput = 30;
int yput = 20;
int bitmapOffset = 0;
// color to draw the text
int r = 255;
int g = 0;
int b = 0;
foreach(y; 0 .. height) {
if(y + yput >= image.height)
break;
foreach(x; 0 .. width) {
scope(exit) bitmapOffset++; // always advance this as long as
we're still drawing...
// but don't draw out of bounds
if(x + xput >= image.width)
continue;
// replace a pixel with the blended version of the text
bitmap
image.setPixel(
xput + x, yput + y,
image.getPixel(xput + x, yput + y).
alphaBlend(Color(r, g, b,
bitmap[bitmapOffset]))
);
}
}
import arsd.png;
writePng("text-image.png", image); // save it back to a png
}
---
Open the text-image.png to see the result. (Or:
---
import arsd.simpledisplay;
displayImage(Image.fromMemoryImage(image));
---
to display it in a window right from your program!)
My libs are available as individual files from the github - you
might just use png instead of the whole image.d to avoid needing
additional files for formats you don't need - or you can pull it
on dub under the arsd-official:image_files package and
arsd-official:ttf.
Re: A template construct like using()
On Tuesday, 26 April 2022 at 23:00:57 UTC, cc wrote: If your draw code doesn't depend on any scoped state you can use `function()` instead of `delegate()` to save a GC call. `scope delegate` also works here and just reuses the stack.
Re: Beginner memory question.
On Saturday, 16 April 2022 at 20:41:25 UTC, WhatMeWorry wrote: Is virtual memory entering into the equation? Probably. Memory allocated doesn't physically exist until written to a lot of the time.
Re: TIC-80 WebAssembly: pointers to fixed addresses
On Saturday, 16 April 2022 at 14:29:09 UTC, Pierce Ng wrote:
```
pub const FRAMEBUFFER: *allowzero volatile [16320]u8 =
@intToPtr(*allowzero volatile [16320]u8, 0);
pub const TILES : *[8192]u8 = @intToPtr(*[8192]u8, 0x4000);
pub const SPRITES : *[8192]u8 = @intToPtr(*[8192]u8, 0x6000);
```
I believe the above is declaring that FRAMEBUFFER is a pointer
to 16320 (sic) bytes starting at address 0, TILES is a pointer
to 8192 bytes starting at address 0x4000, and SPRITES a pointer
to 8192 bytes starting at address 0x6000.
Currently for D I have the following, copying the D binding for
Wasm4, another fantasy console:
```
const FRAMEBUFFER = cast(uint*)0;
const TILES = cast(uint*)0x4000;
const SPRITES = cast(uint*)0x6000;
```
How to express in D, similarly to Zig, that FRAMEBUFFER refers
to a byte[16384] array starting from address zero, and so on?
Take the pointer and slice the pointer:
__gshared ubyte[] framebuffer = (cast(uint*) 0) [0 .. 16320]; //
gshared cuz otherwise D assumes it is TLS and it isn't
Now you can notice it isn't const. You don't want it const since
the point is to write to the thing. What you might do to keep the
pointer itself from ever changing is to make it a property:
ubyte[] framebuffer() { return (cast(uint*) 0) [0 .. 16320]; }
And the compiler will see how trivial that is and inline it so it
works the same way, but then nobody can ever rebind the
framebuffer symbol.
Re: arsd.minigui
On Sunday, 3 April 2022 at 16:58:03 UTC, JG wrote:
Hi,
I have an png image that I generate (via pdf via pdflatex) that
I want to scale and display in a widget. Is this possible via
something in arsd? I tried resizeImage but that doesn't seem to
do what I expect. Any suggestions?
Which resizeImage did you use, from the imageresize module? What
pain you have with it? Some of its settings take some tweaking.
Though in a widget, you can also stretch automatically on
Windows... actually XRender can do it too i believe but I never
implemented that. Maybe I should.
But imageresize should work with some experimentation. This is
how I did it in my image viewer application:
auto i = loadImageFromFile(arg);
auto size =
calculateSizeKeepingAspectRatio(i.width, i.height, maxWidth,
maxHeight);
if(size.width != i.width ||
size.height != i.height) {
i = imageResize(i,
size.width, size.height, null, 1.0, 0.6);
}
then pass that i to one of the minigui/simplediplay functions to
display.
Re: arsd-minigui - couple of questions
In fact, using a pragma now, I think I got it so you don't even need the manifest now (the pragma includes a default one now). Only works when doing dmd -m32mscoff or dmd -m64 builds (which are also what dub uses fyi), will NOT work with a default dmd no-switch build.
Re: arsd-minigui - couple of questions
oooh it actually is even easier than I thought, just a changed flag plus the manifest. Just pushed to minigui master. only ended up being 4 lines for this little thing. Try rebuilding with that AND be sure to use the manifest file too, same as dwt. Then you should be able to find some joy.
Re: arsd-minigui - couple of questions
On Monday, 28 March 2022 at 21:10:47 UTC, Sai wrote: FWIW, DWT which uses native controls on windows can show transparent pngs and also both image & text at the same time. However I had to add the following app.exe.manifest Yeah, this tells me they used owner-drawn buttons, which is only supported if you use version 6 controls. The version 6 controls are nice btw even if you don't use this specific feature, they also come with automatic theme support and a few other nice things. I actually recommend in the docs that you use this for simpledisplay/minigui applications too, just then you also need to provide a draw method to do the text+image. It isn't hard to do, about a dozen lines for this basic case that you can just opt into and use the default draw for other cases. I was thinking about adding one of those anyway (another nice thing you can do is change the background color), I just haven't gotten around to it yet. Maybe I'll do it tomorrow. Keep an eye on this thread, if I do, I'll let you know.
Re: arsd-minigui - couple of questions
On Monday, 28 March 2022 at 17:00:42 UTC, sai wrote: 1. I assume arsd-minigui library does not support transparent images by itself, does it? I am trying to show a png image with transparent areas on a button, but those transparent areas shows as black color. Well, I tried forwarding the flag, I can custom draw it this way but the standard Windows button's normal draw doesn't appear to care... There might be a trick I just don't know, but the problem is I don't know it lol.
Re: arsd-minigui - couple of questions
On Monday, 28 March 2022 at 17:00:42 UTC, sai wrote: 1. I assume arsd-minigui library does not support transparent images by itself, does it? I am trying to show a png image with transparent areas on a button, but those transparent areas shows as black color. I added that to simpledisplay last year, but never forwarded the flag to minigui since it didn't seem important should be easy enough to add, I'll take a look. 2. I want to show both image and text on a button, but looks like it shows image or text, but not both at the same time. Or am I missing some weird windows manifest stuff? Yeah, it is one or the other right now. I don't think the standard Windows control supports that without owner draw, which is something I've generally tried to avoid (but it isn't that hard to do at least in some cases...).
Re: Basic question about size_t and ulong
On Friday, 18 March 2022 at 21:54:55 UTC, WhatMeWorry wrote: Isn't ulong an integer? And isn't memory addresses 64 bits long? Only if you are doing a 64 bit build. Try using -m64
Re: argparse version 0.7.0 - a CLI parsing library
On Friday, 18 March 2022 at 18:21:46 UTC, Anonymouse wrote: 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 approach you might consider is a hybrid too, where you have the big struct you build out of the individual udas. So you work on the big one but you do getBig!decl and it loops through the members of thebig struct and sees if the same-typed UDAs are on decl. If so, it loads them in, if not, it leaves default values. Then the user can write it either way and you always process it simpler.
Re: static init c struct with array filed
On Thursday, 17 March 2022 at 00:16:39 UTC, Mike Parker wrote:
On Wednesday, 16 March 2022 at 07:27:06 UTC, test wrote:
```c
struct Test {
int32_t a;
}
struct Test2 {
int32_t a;
Test arr[];
}
```
I need static const init Test2, then pass it to c library
late(third library, can not change the type def).
Any time you see a '[]' in C, the equivalent declaration in D
has to be a pointer.
Not always with structs... if it has a fixed size or an
initializer in C, then you need to match the size in D.
Otherwise yeah use the pointer.
Re: From the D Blog: The Binary Language of Moisture Vaporators
On Monday, 24 January 2022 at 22:45:14 UTC, Ali Çehreli wrote: I am not aware of any association between "alpha" and "man" because I hear both "alpha male" and "alpha female" in e.g. nature documentaries. It isn't really accurate in nature either and when used with people it tends to be exaggerated to the point of being totally absurd.
Re: D Language Quarterly Meeting Summary for January 2021
On Sunday, 23 January 2022 at 15:35:17 UTC, Paul Backus wrote: The main benefit of having multiple versions available in separate namespaces is that it allows them to coexist in the same project, which means that users can migrate their code incrementally from one to the other. Yeah, I know the theory, but in practice this has limited value and works best for more fine-grained things (e.g. keeping deprecated individual functions around are more helpful than whole modules). The bigger the thing, the more likely that you'll actually introduce more bugs and compatibility issues trying to keep both versions working anyway. In principle you could also accomplish this with a versioned dub package and mangle-prefix [1], but progress on that initiative seems to have stalled out. Well, that's because it was a hopeless idea from the beginning. The in-language `import` doesn't know anything about mangles, so this concept was just asking for trouble. It would work if any only if the dependencies were *completely* isolated, but even something as simple as you importing library A who uses v1.struct at the same time as library B who uses v2.struct - even if lib A and lib B's usage of that struct was entirely `private` - is liable to cause ABI crashes. Something like PIMPL can still make it work, but there's no guarantee they did that, and likely no expectation that they would in typical D code. Anyone who has debugged extern(C) crashes after a library update knows these situations are not fun.
Re: D Language Quarterly Meeting Summary for January 2021
On Sunday, 23 January 2022 at 14:33:26 UTC, Paul Backus wrote: Absolutely-no-breakage-ever is basically the C++ approach, and I have already explained why I think it's a bad idea, though I recognize that reasonable people can disagree on this point. My view is it isn't worth shipping mixed versions at all. I'm against gratuitous breakage; it should actually provide a benefit, and I'm against dead-end breakage; it should provide a migration path. But if there's a path to a benefit, people need to make a choice: take that path, or stop updating. Any middle ground is temporary at best anyway.
Re: forward tuple arg to local variable + dtor
You can't forward to a local variable. Local variables will be a copy of the tuple. forward only actually works if sent *directly* to another function call. There's a bunch of things in D that only work in function parameter lists and not local variables. This is one of them.
Re: Using getSymbolsByUDA in a static foreach loop
On Thursday, 20 January 2022 at 00:55:33 UTC, Jack Stouffer wrote: static foreach(member; __traits(allMembers, Manager)) member here is a string, not the member. I prefer to call it memberName. Then you __traits(getMember, Manager, memberName) to actually get the alias you can pass to getAttributes.
Re: Ambiguity issue with expanding and evaluating single template type parameter enums
On Tuesday, 28 December 2021 at 00:13:13 UTC, data pulverizer wrote: There are various requirements, sometimes I have to cast or type convert, so I **need** the type to paste correctly and explicitly. You almost never actually need types as strings. I'm almost certain there's a better way for you to get the same work done. Have you tried just using T directly in your mixin? You can frequently just use the local name and skip the string getting entirely.
Re: Ambiguity issue with expanding and evaluating single template type parameter enums
On Monday, 27 December 2021 at 21:21:30 UTC, data pulverizer
wrote:
alias T = MyType!(INTEGER);
What is MyType?
enum code = "writeln(\"instance: \", adder(" ~
T.stringof ~ "(), " ~ U.stringof ~ "()" ~ "));";
And why is this a string mixin instead of a plain simple function?
prolly need more context
Re: Ambiguity issue with expanding and evaluating single template type parameter enums
On Monday, 27 December 2021 at 21:05:51 UTC, data pulverizer wrote: adder(MyType!MyEnum.INTEGER(), MyType!MyEnum.STRING()); The rule for !(args) is of you leave the parenthesis off, it only uses the next single token as the argument. So it will never include a dot; it is like you wrote `MyType!(MyEnum).INTEGER`. You might just always use the () in your generated code when you create that mixin string can't just just change the generator to put the () around it? Or is the stringof generating this? (Another reason why stringof is terrible and should never be used ever for anything.) `MyType!MyEnum.STRING` is generated with `T.stringof `. I get the error: if you can paste teh code where you generate this I can prolly show you a much easier way to do it. stringof sucks really hard.
Re: How to print unicode characters (no library)?
On Sunday, 26 December 2021 at 20:50:39 UTC, rempas wrote: I want to do this without using any library by using the "write" system call directly with 64-bit Linux. write just transfers a sequence of bytes. It doesn't know nor care what they represent - that's for the receiving end to figure out. know (and tell me if I'm mistaken), UTF-16 and UTF-32 have fixed size lengths for their characters. You are mistaken. There's several exceptions, utf-16 can come in pairs, and even utf-32 has multiple "characters" that combine onto one thing on screen. I prefer to think of a string as a little virtual machine that can be run to produce output rather than actually being "characters". Even with plain ascii, consider the backspace "character" - it is more an instruction to go back than it is a thing that is displayed on its own. Now the UTF-8 string will report 11 characters and print them normally. This is because the *receiving program* treats them as utf-8 and runs it accordingly. Not all terminals will necessarily do this, and programs you pipe to can do it very differently. Now what about the other two? I was expecting UTF-16 to report 16 characters and UTF-32 to report 32 characters. The [w|d|]string.length function returns the number of elements in there, which is bytes for string, 16 bit elements for wstring (so bytes / 2), or 32 bit elements for dstring (so bytes / 4). This is not necessarily related to the number of characters displayed. Isn't the "write" system call just writing a sequence of characters without caring which they are? yes, it just passes bytes through. It doesn't know they are supposed to be characters...
Re: How to pass a class by (const) reference to C++
On Wednesday, 15 December 2021 at 22:24:42 UTC, H. S. Teoh wrote: `__gshared` is needed to coax the compiler into making the variable global in the C/C++ sense, i.e., only 1 instance across all threads. it is just normally __gshared implies static automatically. it does in like every other context but i guess not in the mangler or whatever.
Re: Beta 2.098.1
On Sunday, 12 December 2021 at 22:01:57 UTC, Martin Nowak wrote: http://dlang.org/changelog/2.098.1.html 404'd!
Re: Why code failed to compile for foo2?
On Saturday, 11 December 2021 at 23:17:17 UTC, Stanislav Blinov wrote: ? No. If it was unsatisfied constraint, the error would've shown that. And if you try to instantiate it, you'll see it is an unsatisfied constraint anyway. There's two layers of failure here. Using Unqual there is pretty iffy, i wouldn't bother with it at all, but if you do anything, instead qualify it const. But either way, then the constraint still fails since int isn't unsigned. I'd really recommend simplifying this a lot.
Re: Why code failed to compile for foo2?
On Saturday, 11 December 2021 at 22:50:45 UTC, apz28 wrote:
void foo2(T)(Unqual!T x) if(isUnsigned!T) {}
This means it treats foo2 as if it doesn't exist unless T is
unsigned...
onlineapp.d(15): Error: template `onlineapp.foo2` cannot deduce
function from argument types `!()(int)`
onlineapp.d(7):Candidate is: `foo2(T)(Unqual!T x)`
*/
And this is telling you it had a signed value - int - which means
it doesn't match.
For the other ones, the functions still exist, so it does
whatever conversion it needs. Whereas with the template that
constraint means the compiler acts like it doesn't exist at all
and thus doesn't even attempt an automatic conversion.
Re: T... args!
On Wednesday, 8 December 2021 at 23:43:48 UTC, Salih Dincer wrote:
Is this not a contradiction? : and 3.1415 aren't string:
```d
void foo(string...)(string args) {
`string...` there is a user-defined identifier representing a mix
of types.
string isn't special, yo can declare your own variables with that
name. And that's what you did here.
I think you meant to say
void foo(string[] args...) {}
which is avariadtic number of only strings
Re: How to read a single character in D language?
On Friday, 19 November 2021 at 20:51:09 UTC, BoQsc wrote: But the source file overwhelmed me by its size. Yeah, the getch function in there builds on the rest of the events the library offers, so it won't be that useful outside. The OS functions for getch alone though are actually pretty simple: 1) change the terminal to "raw" mode. the default is to buffer lines, which means your application doesn't get anything until a line is complete. You need to turn that off. The RealTimeConsoleInput constructor does this in the lib: http://arsd-official.dpldocs.info/v10.3.8/source/arsd.terminal.d.html#L2487 On Windows, you basically just call `SetConsoleMode`, but since the console is a shared resource, you also need to save the old mode to set it back later (that's what I do in the destructor of the struct). On Linux, you call `tcsetattr`. The function for mine is here: http://arsd-official.dpldocs.info/v10.3.8/source/arsd.terminal.d.html#L2620 Again, the terminal is a shared resource (this is actually even more true on linux systems!) so it is important to save the old one and set it back when you're done. There's a lot of ways this can happen so you should handle them all - that's why there's a bunch of signal handler blocks there. Other things the library initialize is if you want echo, mouse input, paste events, resize notifications, etc. But if you only care about getch you can ignore most that stuff. 2) Read the terminal's event stream. On Windows, you call `ReadConsoleInput` and process the struct it sends you for a keyevent. See: http://arsd-official.dpldocs.info/v10.3.8/source/arsd.terminal.d.html#L3122 On Linux, you call the system `read` function on the stdin stream (file number 0). Basic keys will come as a single byte read on there. Others get extremely complicated. http://arsd-official.dpldocs.info/v10.3.8/source/arsd.terminal.d.html#L3369 And it goes on for about 400 lines! And it depends on some of that other initialization we skipped over before and uses a database of terminal quirks found elsewhere in the file. Windows' API is far, far easier to use. But the Linux one isn't bad if you only want basic alphanumeric and enter keys. You can read those as a single ascii byte off the read function, so for that you can do it in just a few lines. 3) Again, remember to set it back how you found it before you exit by callling the SetConsoleMode/tcsetattr again before you exit.
Re: arsd.simpledisplay on macos
On Tuesday, 16 November 2021 at 03:41:31 UTC, Ben Jones wrote: I'm trying to use Adam's simpledisplay on a mac with XQuartz which is installed + running. When I try to create a window, it crashes when calling `XDisplayConnection.get()`. Hmm, I have never actually seen that fail since the mac will start up the X server on demand. Nevertheless, you might want to try a few things: 1) run xquartz separately to ensure it is up 2) set hte DISPLAY=:0 environment variable before starting the sdpy app 3) also perhaps try DISPLAY=127.0.0.1:0 in case it isn't configured for it Also possible I bugged it since then though, since it dynamic loads the libs instead of static and I never actually tested that fully on mac. But I think if that was the case you'd get an abort instead of an exception; it wouldn't get to the connection failed step. r is there an example that seems to work with the native cocoa version? I'm only planning to use really basic functionality (display an image and maybe capture some key presses) I actually don't think the key press functions work anymore, but they are probably fairly easy to fix. You have to build it without dub so you can pass -version=OSXCocoa to the compiler. Then some things at least should work. But the Cocoa implementation was contributed to me back in like 2012 and I've spent very little time on it since then. At one point last year, I did get its window working again at least but not much else. It is liable to throw NotYetImplementedExceptions and might have regressed since then too. I have a mac vm i set up but it is a pain to use so I rarely bother Also, Adam, if you have an idea of what needs to be done to get native macos support working, I'm willing to try to give it a shot. So the existing code is an implementation of just the basic featureset built on extern(C) objc_msgSend calls. It is really ugly code and nothing I've added since 2012 works in there at all - anything more than the basic timer is not implemented, no file events, no opengl, no fonts. Even basic window methods probably won't work like maximize and show. What I'd really like to do is to use dmd's beautiful extern(Objective-C) interface to make the code easier to use. I was kinda hoping those would be added to druntime like core.sys.windows but apparently not. ldc hasn't even implemented the feature at all :( (ive been considering porting it from dmd to ldc myself for like 2 years but it is super low priority since in the rare times i use a mac, im ok with the X server) But yeah I don't know much about mac development and have a trillion other things to do.
Re: D modules
On Saturday, 13 November 2021 at 22:52:55 UTC, pascal111 wrote: When I'm searching for "toUpper" and "toLower" functions that string type uses They are usable though `import std.string;` the docs just don't do a great job showing that. The newest test version of my doc generator does integrate them into the member list though: http://dpldocs.info/experimental-docs/std.string.html My dpldocs.info website has a search engine too to help find the original place: dpldocs.info/toLower for example will point you at std.uni first. But if it is "public imported" into a member list of another module you can use it just importing either way.
Re: in a template, how can I get the parameter of a user defined attribute
On Saturday, 6 November 2021 at 19:45:49 UTC, Chris Bare wrote:
dbForeignKey!(Position)
static if(is(T == dbForeignKey!Arg, Arg)) {
// use Arg here
}
Re: How to do a function pointer to "malloc" and "free"?
On Sunday, 17 October 2021 at 23:07:15 UTC, Elmar wrote: Do you have a link for more information how to initialize the D runtime? Export a function that calls this: http://druntime.dpldocs.info/core.runtime.Runtime.initialize.html And also export a function that calls this: http://druntime.dpldocs.info/core.runtime.Runtime.terminate.html And tell the user to call those when they load/unload the library. (It is pretty common for C libraries to require explicit init/term calls so they should be used to it.) They refcount internally so it is ok to call multiple times, just make sure the init and term are always paired. (btw the druntime actually exports them as extern(C) rt_init/rt_term but I'd still recommend you do your own anyway. if you do have extra work to do you can just do it there, and it can use whatever your lib naming conventions are. and besides im not sure if the extern(C) things are specified stable (even though they have been for as long as i can remember), whereas doing your own thing that `import core.runtime; return Runtime.initalize;` is. )
Re: Beta 2.098.0
On Sunday, 10 October 2021 at 23:11:56 UTC, Walter Bright wrote: ImportC resolves a long standing serious issue where multiple other substantial attempts at solving it have fallen short over the years. Why have the other approaches fallen short? How does importC address these problems?
Re: How to do a function pointer to "malloc" and "free"?
On Sunday, 10 October 2021 at 13:52:57 UTC, Elmar wrote: The language subset "BetterC" is required for calling D functions from C though. This is false. You can use any D features when calling it from C, you just need to provide an init and term function that is called from C that runtime initialize and terminate for the full experience. BetterC helper librarys like Tanya or Tango do exist. I don't know tanya, but Tango has absolutely nothing to do with betterC. It is a set of classes that use the full runtime.
Re: DConf Online 2021 Schedule Published
On Friday, 8 October 2021 at 22:16:16 UTC, Matheus wrote: Adam beyond the continuation... we need a new and simply Web Browser written in D. :) You know back in 2013ish I actually was doing a little one. htmlwidget.d in my github repo. It always sucked but it is tempting to go back to it; with my new functions it would suck slightly less. But realistically I wanted to do something I could finish in one hour and obviously that didn't work so now I gotta finish it in one hour more. Nothing too big can be squeezed in there.
Re: Better debugging?
On Sunday, 3 October 2021 at 22:21:45 UTC, Tim wrote: -gc DMD2 compiler switch tried plain -g ? -gc is a compatibility debug thing for things with zero D support. p oboslete now
Re: Template mixin problem with EnumMembers
On Saturday, 2 October 2021 at 22:07:23 UTC, Ferhat Kurtulmuş
wrote:
The below code works as expected on https://run.dlang.io/, but
not on my computer. And I don't know why?
You used .stringof. That's undefined behavior. Never use
stringof. (except for debugging writes)
Now, I'd actually probably do this entirely differently... just
using opDispatch.
```
class Options{
public:
enum StringOption {
OUT_FILE_NAME,
RPT_FILE_NAME,
MAP_FILE_NAME
}
static template opDispatch(string name)
if(__traits(hasMember, StringOption, name)) {
alias opDispatch = __traits(getMember, StringOption,
name);
}
}
```
and done. (even that `if` template constraint isn't really
necessary and im usally anti-those too, but here it kinda makes
sense. in theory. in practice it makes zero difference, but in
theory, if the dmd regression that broke these error messages
ever actually gets fixed, this would lead to better error
messages this way. but anyway moving on)
That opDispatch just creates the aliases on-demand. You can't
reflect over them directly if you wanted to - you'd still have to
check enum members of Options.StringOption, which means things
like std.conv.to won't pick it up, but it would work in normal
use quite beautifully.
If you did want to do the ahead-of-time static foreach way,
remember, never use .stringof. Find another way.
and tbh i'd ditch the std.traits thing too, it just complicates
things. Use the language feature allMembers directly and it
simplifies to this:
```
mixin template StrOptAliases()
{
static foreach(name; __traits(allMembers, StringOption))
mixin("alias " ~ name ~ " = " ~ " __traits(getMember,
StringOption, name);");
}
```
Notice that the ONLY thing outside the quotes to the mixin is the
name. Everything else is inside. That's often the solution to
follow my "never use stringof" advice - just leave things inside
the quotes. String interpolation / concat is actually very rarely
needed to build mixins. New declaration names are the main
exception. But most everything else can just be referenced
directly and it leads to code that is both less buggy and easier
to read.
And, of course, it doesn't rely on random underspecified
.stringof behavior that the compiler can change randomly in any
release which is just the cherry on top.
Re: Understanding range.dropBackOne
On Tuesday, 28 September 2021 at 22:56:17 UTC, Tim wrote: I'm doing the following: int[25] window = 0; Note that this array has a fixed size. window = someInteger ~ window[].dropBackOne; Here the window[] takes a variable-length slice of it. Turning it from int[25] into plain int[]. Then you can drop one since it is variable length. Then appending again ok cuz it is variable. Then the window assign just copies it out of the newly allocated variable back into the static length array. window = someInteger ~ window.dropBackOne; But over here you are trying to use the static array directly which again has fixed length, so it is impossible to cut an item off it or add another to it. What does the `[]` do exactly? Is an array not a bidirectional range? It takes a slice of the static array - fetching the pointer and length into runtime variables.
Re: Templates for instantiating derived class
On Monday, 20 September 2021 at 22:16:47 UTC, rjkilpatrick wrote:
auto opBinary(string op)(int rhs) const if (op == "+") {
return new Super(_a + rhs); // Creates of type Super
even when called from derived class
}
Make this
auto opBinary(string op, this This)(int rhs) .
return new This(_a + rhs);
}
The template this param is the static type it is called on.
https://dlang.org/spec/template.html#template_this_parameter
Note though that this is the static type. If you do
Super thing = new Derived();
thing + 5;
it will still return Super since that's the type it was called
through. If you want it to actually return derived, you'll have
to add a virtual factory function:
class Super {
protected Super factory() { return new Super(); }
}
class Derived : Super {
override Derived factory() { return new Derived(); }
}
Then you can call obj.factory to get the right dynamic type.
(forward args as needed etc.)
Some kind of `return new this(...)` would be good, but that's
not possible.
You can do `return new typeof(this)(...);` fyi but it is again
the static type of this, which will be whatever it is where it is
defined. This is a useful trick if you were to make that factory
function a mixin template or something though.
Re: SAOC 2021 Projects Summarized
On Wednesday, 1 September 2021 at 22:23:59 UTC, user1234 wrote: I dont know why destructors are not virtual. https://dlang.org/spec/class.html#destructors "There can be only one destructor per class, the destructor does not have any parameters, and has no attributes. It is always virtual. " I guess it is virtually virtual due to the rt_finalize implementation papering it over. But you can write a destroy function to do this too by looking up the base class xdtor as well (I'm pretty sure anyway). My point is really just that protoobject is almost certain to have exactly the same destructor situation as object
Re: interface function member declarations needing parameter attributes ?
On Saturday, 17 July 2021 at 20:42:06 UTC, someone wrote: From the interface perspective: are these signatures identical or not ? No, they are very different. But you also don't gain much from const here and that ref is probably actively harmful so i wouldn't use them here.
Re: function parameters: is it possible to pass byref ... while being optional at the same time ?
On Saturday, 17 July 2021 at 20:49:58 UTC, someone wrote: ref classTickerID robjTickerID Why are you using ref here at all? You probably shouldn't be using it. But if it is legitimately needed you can do a pointer instead of ref.
Re: UFCS doubt
On Thursday, 8 July 2021 at 22:24:26 UTC, Antonio wrote: I supossed that ```mfp(c,20)``` and ```c.mfp(20)``` should be equivalent because UFCS in second example, but it is not... why? UFCS only works with functions defined at top level, not nested inside other functions. That's just how it is defined i don't really know why.
Re: What can be done to reduce executable size?
Jacob Carlborg Wrote: As long as the runtime and standard library is statically linked the executables will be bigger than the corresponding C/C++ executable. I just want to say it's very important to me that static linking still just works very easily even if we start to offer dynamic linking.
Re: D1 to be discontinued on December 31, 2012
Vladimir Panteleev Wrote: This raises a question: will the D1 compiler be made redistributable when it's discontinued? Isn't it already licensed for redistribution by the Tango folks?
Re: Haxe (From: Java Scala - new thread: GUI for D)
Adrian Wrote: [OT] As a side point from a not yet D developer, but someone who looks at the language with great interest, but also someone with a commercial responsibility: I am missing big projects developed in D and the most logic project would be the compiler itself! I know this has been discussed a million times before, but... How big is big? My app is up to about 75,000 lines of D2 (including my D libs), which isn't gigantic but it does a lot of things and needs to be ready for use and changes almost every day.
Re: Comma operator = broken design
Alex Rønne Petersen Wrote: I really do not see the value in allowing such syntax in the first place. I've been told that one argument was that generated code might use it, but I have no idea why it would be needed. Aside from the compiler's implementation, one possible use is something I ended up doing in Javascript recently. I have a thing that takes an attribute and pastes it into a code string to check it. given validate=this.value.length 3 it writes: if(!(this.value.length 3)) return false; // failed validation since the given string is inside an if statement, you can't put a semicolon in there. So, if you have a check more complex than returning a boolean and want to stuff it all in that string (so functions are out), the comma lets you do it: validate=do something, true This is pretty ugly style that I think I've only ever done in D inside a for loop... but the point is sometimes something comes up, and it's nice to have another option available, even if it is ugly.
Re: javascript (was Re: Java Scala - new thread: GUI for D)
Jacob Carlborg Wrote: for e in arr # do something with the element e Heh, I used to think that would work in regular Javascript, since it does have a for(blah in something) form... But in regular javascript, that only works on objects!
Re: javascript (was Re: Java Scala - new thread: GUI for D)
Marco Leise Wrote:
This is really one of the largest shortcomings of the language that can
not be explained with a simple design choice.
Aye. One of the newer versions adds a forEach member to the
array prototype, that works like this:
[1, 2, 3].forEach(function(element) { use element here; });
but I don't like that style, personally. All those years of C
and friends have wired my brain to see it as being backward.
And, it doesn't work for everyone out of the box anyway.
Re: Java Scala - new thread: GUI for D
Jacob Carlborg Wrote: Do you have any opinion about Dart from Google? Google's MO is generally to take something bad... and make it /worse/. It compiles to Javascript, but script that doesn't actually work everywhere...
Re: Haxe (From: Java Scala - new thread: GUI for D)
Nick Sabalausky Wrote: The only problem now is that that would rule out the possibility of sharing code between both server and client - Which is *NOT* something I want to give up... What kind of code is it? The main reason for the javascript api thing in my web.d is to help minimize the pain of duplication, by keeping it all on the server, but still having easy client side interface. Then basically your js is just event glue to various server side functions. Of course, it keeps the JS down to size... but doesn't actually let you run code on the client written in D.
Re: Haxe (From: Java Scala - new thread: GUI for D)
Adam Ruppe Wrote: Of course, it keeps the JS down to size... but doesn't actually let you run code on the client written in D. Unless your client is a real application, of course :P I did a Qt app using the modules from a work web app earlier in the year. I interfaced with Qt via a message passing layer which converted signals and slots into C calls - which were implemented in D. So, new widgets would be written in C++ (QtD was close but not quite good enough for me to use), but the core was still D.
Re: boost crowd.
Do you think it'd be a good thing to put the .di file in the generated compiled lib? That'd be somewhat similar to the c# example. dmd myprog.d something.dll searches something.dll for a .di reference, and adds it to the compile command line if it's there.
Re: newsgroup web viewer
Kagamin Wrote: well, most people here seem to use nntp clients, so their requests (like threaded view) can be safely ignored :) they have it in their clients. Indeed. Hell, I probably won't use it very often, since I have my precious mutt mail client! But, regardless, I wrote that already and just need to tweak it now, so not a big hassle.
Re: newsgroup web viewer
Nick Sabalausky Wrote: a:link vs a:visited That was my original plan, but I like having multiple posts on one page too, and you can't link them up that way. Or can you? Maybe with script, I can watch the scroll position and change the anchor as each post scrolls into view. The anchor could be used as a link target. But if you view posts individually: http://arsdnet.net/d-web-site/nntp/get-message-page?newsgroup=digitalmars.DmessageId=%3Cop.v4yfbjy4tuzx1w%40cybershadow.mshome.net%3Eoriginal You have that same reply to list, parent link, etc. people want, and the browser history keeps track of where you've been.
Re: newsgroup web viewer
Vladimir Panteleev Wrote: Hmm... Now what do I do with the half-written thing I started writing two days ago (for news and newsgroups)? We could always combine the best parts of both of them!
Re: newsgroup web viewer
Walter Bright Wrote: It's trivial with a news reader, because unread messages are in boldface. Which is possible because the messages are sorted linearly in the computer! When you do a newnews command in NNTP, you tell it a time, not a thread. Then it grabs everything since that time, and you know they are new. Hmmm that's an idea though. If it plopped down a last checked time cookie or url param, it could bold the new things on the web too.
Re: newsgroup web viewer
Peter Alexander Wrote: Would this encourage vandalism? If people know they can get a post on the front page of the D website just by posting to D.announce then I think we could see some trouble. Meh, I say we cross that bridge when we come to it. Right now, the D newsgroups have a pretty good record; most the people who post here are honest and well enough on topic. Until that changes, I wouldn't worry about it.
Re: newsgroup web viewer
Jonathan M Davis Wrote: Knowing the parent post of a particular post can be critical to understanding that post - especially when the parent post isn't quoted in the reply. Yeah, that's one of the few times I hit the o-t keys in my mail reader to sort by thread. Keep in mind that this information is always available! I just don't like using it by default. Particularly with longer threads, I don't know how you could ever hope to follow them without having a properly threaded tree structure to the posts. I've never had trouble following linear threads, even with hundreds of posts. But looking at a tree thread is almost impossible once it gets to more than about ten posts without computer assistance, and even then, it's so fractured that people repeat themselves a lot. Even gmail - which has threading of a sort - is completely inadequate to dealing with complex threads. Gmail sucks on so many levels. Their interface is almost unusable.
Re: newsgroup web viewer
bcs Wrote: Cut the tab size by about 60% and that's usable. OK OTOH it will still end up with a column size of -10 pt about the time threads get interesting. Another fundamentally broken aspect of tree views. And if anyone keeps more than about 3 layers of quoting you need to be Tolstoy to be more than half the content. Well, the way I see it, if you're quoting more than two lines at a time, you're probably over-quoting. Remember, in both linear and tree views, getting back to the parent post is very easy, and if someone is reading the reply, it is likely that he read the parent already anyway. I hit the N key or look for the bold titles. How is that N key implemented? boldEach(find!a.timestamp b(sort!a.timestamp b.timestamp) (messages)); or something like that.
Re: newsgroup web viewer
Walter Bright Wrote: If that sin isn't enough, the other problem is there is no way to mark a post as read. Every linear view web forum software I've ever seen handles this automatically. I don't really love the implementation of most of them, but they usually do a good enough job anyway. That's the main thing that sux about Reddit. Try reading a topic for a while, then come back a few hours later and wonder what's new. Aye. Reddit is one reason why I don't like tree views!
Re: Dynamic alter-ego of D.
You can use opDispatch to make runtime methods and properties
by having it forward to a function to do the lookup.
Something alone these lines:
DynamicObject delegate(DynamicObject[] args) dynamicFunctions;
DynamicObject opDispatch(string name, T...)(T t) {
if(name !in dynamicFunctions) throw new MethodNotFoundException(name);
DynamicObject[] args;
foreach(arg; t)
args ~= new DynamicObject(arg);
return dynamicFunctions[name](args);
}
I've done a more complete implementation before, but don't have
it on hand right now.
Re: FastCGI binding or implementation?
Andrea Fontana: other http methods have nothing special Indeed. The only thing that might get you is if the data's content type is different than the default. That's possible on POST too, though, so still nothing special. My cgi library has an enum to tell you what the requestMethod is, and it lists all the options in the standard. It, however, does not handle all possible content-types. It does x-www-form-urlencoded and multipart/form-data, so it can handle virtually all web forms out there - including file uploads - but if you want others, it'll take a minor modification. The best way to do it is probably to not attempt to parse it in the library at all, and just pass a range of raw data to the application.
Re: xml Bible for conversion for D
I found std.xml useless too, so I wrote my own lib.
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff
Grab dom.d from there. First, convert your file to UTF-8. My lib
might work for you, but it assumes utf-8 so it will throw if it actually
encounters a non-ascii character from the 8859-1 charset.
Anyway the D code for dealing with that would look something like this:
import std.file;
import std.stdio;
import arsd.dom;
void main() {
auto document = new Document(readText(bible.xml));
// the document is now the bible
auto books = document.getElementsByTagName(b);
foreach(book; books) {
auto nameOfBook = b.n; // Genesis for example. All xml attributes are
available this same way
auto chapters = book.getElementsByTagName(c);
foreach(chapter; chapters) {
auto verses = chapter.getElementsByTagName(v);
foreach(verse; verses) {
auto v = verse.innerText;
// let's write out a passage
writeln(nameOfBook, , chapter.n, :, verse.n, , v); //
prints Genesis 1:1 In the beginning, God created [...]
}
}
}
}
Re: FastCGI binding or implementation?
Jacob Carlborg: Why not just cache the generated HTML and let Apache handle it. That sounds hard... configuring Apache to do anything beyond the most trivial of tasks is a huge pain to me. It is easy to call cgi.setCache(true); though. Then it doesn't even need to start the application if the cache is available. It's better with a client side cache. If it's available, you don't have to go to the server at all! Server side caching is something I haven't done yet; it's never been useful to me.
Re: [std.database]
Andrei Alexandrescu wrote: The database engine should be codified in the connection string, not in the type name. Why? If it's in the type, you can trivially specialize for different engines and get static checking for functions not supported across them all, or runtime checking if you prefer. You can also change the constructors to make it clear what is being created.
Re: [std.database]
The way I'd do it is:
interface Database {
// support shared functions here, and other stuff useful enough to
// warrant emulation
}
class Postgres : Database {
// implement the interface, of course, but also all other postgres
// specific stuff
}
When you go to use it, if you're happy with the basics, declare
Databases.
If you need something special, use Postgres objects.
Re: how to build up the library..
What's the big advantage of Person.find_all_by_name_and_age(Joe, 15) over db.query(select * from people where name = ? and age = ?, Joe, 15); The latter is much easier to write in the library and you retain all the flexibility of sql itself if needed.
Re: Database interface design - was how to build up the library.
In my database.d, I used a database row struct to provide both integer and key based indexes.
Re: Database interface design - was how to build up the library.
Sean Kelly wote:
Does your Row equate to the ResultSet above?
Fairly similar.
Mine looks something like this:
interface ResultSet {
// name for associative array to result index
int getFieldIndex(string field);
string[] fieldNames();
bool empty();
Row front();
void popFront();
int length();
}
struct Row {
// the actual column is returned as a string - probably should
// change that, but mysql, postgres, and sqlite all offered that
// and it works for me, so I went with it
string opIndex(size_t idx) {}
string opIndex(string columnName) {}
int opApply(...) {}
private string[] data;
}
Then, each of the database implementations use that little
ResultSet interface to feed Row structs back to the user code.
Re: std.getopt suggestion
Andrei wrote: We don't kind of have a MySQL library. We just don't have one. Actually, we have three or four. Maybe more. There aren't any in phobos, but they are still fairly easy to find. (Or hell to just wrap C takes less than an hour.)
Re: std.getopt suggestion
Andrei wrote: link to a few There's mine: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff see database.d and mysql.d for mysql. Also some code for postgres and sqlite in there own modules. Piotr Szturmaj's is postgres only, but generally vastly superior to my postgres module: http://www.digitalmars.com/d/archives/digitalmars/D/learn/D2_postgresql_interface_-_Phobos2_23693.html You remember Steve's post from a week or two ago. There's also this one I've heard of: http://www.dsource.org/projects/ddbi I'm sure it's ancient, but there might be something to use there. I'm pretty sure there's more but this is what I know off the top of my head.
Re: version vs. static if
I hope there's no D3 for a very long time. Maybe 2020.
Re: version vs. static if
There's several reasons backward compatibility is important: 1) Breaking it annoys me. There's still stuff I like for new features, so I'm not at the point where I'll never update again yet, but I don't want my code to break more. Especially if non-trivial. 2) It splits people. Suppose you grab a lib and it uses D3 features. If you're on D2, you can't touch it. 3) It gives a perception of instability. There's already enough complaints on this about D1 and D2. With the costs, the benefit has to be huge to break compatibility.
Re: Paradox about D's popularity.
SWIG kinda scares me... doesn't it generate wrappers instead of direct calls into the C++? That could easily double the size of the library. There's a bugzilla entry with a thing to allow calling into more of C++'s functions with extern(C++). I'd like to see that pulled into the tree if it passes Walter's eye. http://d.puremagic.com/issues/show_bug.cgi?id=4620
Re: Anonymous function syntax
deadalnix wrote: This makes Javascript's and D's closures the most readable for somebody having this background. Indeed! I find most the proposed lambdas to look like random noise. D has it good just how it is.
Re: How can I use D to develop web application?
zsxxsz wrote: I think the cgi module is lower effecient. That's not really true. The reason CGI has a perception of being slow is because it's used by slow languages most the time, but with D, it's fast. That said, if you still want to use fast cgi, just use -version=fastcgi when compiling with that same module.
Re: How can I use D to develop web application?
zsxxsz wrote: The fork process is expensive for any OS. Have you actually measured this? I feel the cgi library is too simple, so I doubt wether it supports fcgi for Apache, Nginx or other Webserver. Have you actually looked at it? I've personally used it on three web servers (IIS, Apache, and an embedded server) across two operating systems (Windows and Linux) and three protocols (CGI, FastCGI, and raw http). It'll probably work on other servers and operating systems too, but I haven't tried yet.
Re: Line lengths discussed in eclipse forum and on reddit
Andrei Alexandrescu wrote: Surely you're jesting. Partially. For the most part, the metric system is better for science, but for day to day stuff? Poo. Lots of silly things to remember and the numbers don't line up well to regular stuff. Could be due to the fact that I'm more used to it, but it's more likely that my preferences are objectively superior to anyone who disagrees :) Zero degrees Celsius is the water freezing temperature, which is a very practical influencer (snow vs. rain, plants, crops, etc). Zero degrees is just as arbitrary for that value as thirty-two degrees. It's not easier to remember, nor does it simplify calculations, especially since other constants are so random looking. (what's 1g for force of gravity? The specific heat of water? Standard temperature and pressure? All ugly numbers...) But hey, whatever levitates your nautical vessel. Pro-metric arguments just tend to annoy me because they like to focus on irrelevant trivia, but the truth is they are both arbitrary and ugly. My preference is just less ugly :-P
Re: Line lengths discussed in eclipse forum and on reddit
Andrei Alexandrescu wrote: Well I agree to that, but allow me to note that it's only one post away you mentioned 0 as a memorable number. I might have been unclear - it's not so much that it's memorable, but it has a different gut reaction. Below zero in my gut is akin to saying it's off the scale; it implies a big extreme in subjective perception rather than a specific physical quantity. If you say it's below zero on the Celsius scale, it's literally freezing cold, but it's not an uncommon or exceptional thing. It's below zero through almost the entire winter (and half the spring and fall, at least up here). But, if you say the same thing with the Fahrenheit scale, that is actually fairly special, even in winter - below zero Fahrenheit is pretty cold.
Re: std.stdio overhaul by Steve Schveighoffer
Walter Bright wrote: I don't think that is the reason PHP is such a bear to work with. It is one of the problems with PHP, but I'm not sure it applies to D the same way. Almost *every time* I write PHP, I either mess up a name or the argument order. (Sometimes, PHP functions go src, dest, and sometimes it's dest, src. Ugh! The worst part is it doesn't even catch this. A name mismatch throws an error when it's run. Reversed arguments just silently do the wrong thing.) The random argument order is a huge huge pain. Contrast with D, where I've almost never forgotten a name. Granted, it might be due to my auto-complete function so I type once and only once, but it just hasn't been a big deal. Thanks to the UFCS with arrays, the argument order is almost always the same to work with that, so the much bigger problem never occurs.
Re: std.stdio overhaul by Steve Schveighoffer
Walter Bright wrote: I agree that the XML and JSON libraries need to be scrapped and rewritten. Ugh, I actually use the std.json. Furthermore, in order to work successfully, gofix [...] The easiest way to do that is run the compiler. If an error occurs, go to the given line of the problem and maybe automatically replace with the spell checker's suggestion. Then in case that's wrong, ask the user to confirm it. ... which is pretty much what my editor (vim) already does! Changing names is annoying, but it's not a difficult task, with what we have now. The compiler already does 90% of the work, and even fairly simple editors will bring it to about 98%. I'll bitch about it, but it isn't a big enough deal to bother with a gofix. Trivial fixes are already trivial fixes. I'd prefer to avoid them, but let's not forget that the compiler already does most the work. The more annoying changes are where stuff changes wholesale, so the code needs to be rethought, data needs to be changed, and so on. These are just huge sinks of pain. And, no, a long deprecation time doesn't change anything. Whether I spend thousands of dollars today changing it or thousands of dollars in six months changing it, the fact is I'm still out thousands of dollars.
Re: std.stdio overhaul by Steve Schveighoffer
Andrei Alexandrescu wrote: What should we use? xml2? That might be a good idea. If D modules were to get in the habit of writing their major version numbers as part of the name, it'd solve this as well the dget automatic library downloading thingy in one go. Going with new and old won't work if there should ever be a version 3 written.
Re: std.stdio overhaul by Steve Schveighoffer
Jacob Carlborg wrote: I prefer to use old_. There's two big problems with that though: 1) It still breaks the old code. It's an even easier fix, so this isn't too bad, but it is still broken. 2) What if a third version of a module comes along?
Re: std.stdio overhaul by Steve Schveighoffer
Jacob Carlborg wrote: You can always keep your own local copy of a module. Yeah, though that comes with it's own set of pains. But, let me ask you this. Which is better? 1) Ask an unknown number of people to change their code to keep up with your changes and/or distribute the old module or 2) Ask just one person - who is making changes anyway - to make one more small change and distribute the old and new modules. One counterpoint to this would be why make people download old modules they don't need in the zip? There's two answers to that too: a) That's a trivial cost. The average Phobos module is about 3 or 4 kilobytes once zipped up. When you're grabbing a 10 MB zip, three kilobytes is nothing to worry about. b) If it is a big deal, changing to a download on demand system (like the DIP) can avoid this... especially if the old version is still around and easily accessible by name.
Re: std.stdio overhaul by Steve Schveighoffer
Andrej Mitrovic wrote: select deprecated functionality The problem I have is old code isn't going to change itself to select old functions. New code, on the other hand, can decide to use new functions since someone is actively writing it. Therefore, it's less painful to opt in to using new code than to select to use old code. Naming modules xml.old1 [...] I'd do xml and xml2 rather than xml.old since the name is already xml, and in my view, that's immutable now. This might be a poor man's version control system, but is that bad? It's not uncommon for software (or books or movies...) to have major versions (sequel numbers) in the name. Thanks to D's module namespacing, that name is the only place it'd be too; the code that uses it still looks natural. It's not like they'd have to write parseXML2() all over the place - like is somewhat common in C. Would people find it weird that versions are in the name? Maybe, but again, that's common in a lot of places. Just make sure the Phobos docs point to the newest version by default in the left nav panel so people don't have to hunt for what's newest. Would this naming scheme be a hassle in the source control? I don't think so. 1) If it's a rewrite, it's a different file anyway, even if you gave it the same name; it's not like a patch could apply to both versions. 2) If it's a minor fork, you could surely just apply patches to two branches in git, right? (I don't really know how it works, but I can't imagine it'd be harder than any other branch which I hear git makes easy.) 3) If it's backward compatible, no need to change the number. My only regret is we didn't have the foresight to call it std.xml1 in the first place.
Re: std.stdio overhaul by Steve Schveighoffer
Andrej Mitrovic: I assume people will just pick the first thing they see That's why the links on the left should always point to the newest version, and there might be notes in the docs pointing people to newer and older versions. std.xml looks standard so they would pick that over std.xml2 Maybe, but if were just consistent with a scheme, I think it'd be easy enough to learn. It's not uncommon to see sequels named name 2.
Re: std.stdio overhaul by Steve Schveighoffer
Daniel Murphy wrote: How could [moving a module to your own code] be made easier? Actually, ironically enough, removing it from Phobos would make it easier, since they the file can simply be copied into my own tree without needing to rename it to avoid conflicts. This wouldn't apply to a hypothetical std.xml2 though, if it was still called std.xml. Then the old code would still need to find all the imports and rename it. (Renaming modules will probably get more annoying as we go forward, since function local imports might encourage more repetition of the module name.)
Re: std.stdio overhaul by Steve Schveighoffer
Count me as another who is sick and tired of the gratuitous breaking changes every damned month. The worst part is there's still some new stuff I actually want each month, so I'm not doing my usual strategy of never, ever, ever updating software. It's just pain. Trivial changes are easy enough to fix, but are a pain. More complex changes cost me time and money. (I'm still angry about the removal of std.date. But soft deprecation is even worse - I hate that so much the first thing I do when updating my dmd is to edit the source to get that useless annoying shit out of there)
