Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 20 January 2023 at 11:28:23 UTC, thebluepandabear
wrote:
Hi,
In Java/C# you can create purely static classes.
These are classes whose methods are all static, the classes
cannot be derived from or instantiated:
```
static class Algo {
void drawLine(Canvas c, Pos from, Pos to) { .. };
}
```
Class in use:
```
Algo.drawLine(new Canvas(), new Pos(5, 3), new Pos(7, 9));
```
But why not have drawLine just be a free function?
```
import bluepandastuff.algo;
auto canvas = new Canvas();
drawLine(canvas, Pos(5, 3), Pos(7, 9));
// Or, using UFCS:
canvas.drawLine(Pos(5, 3), Pos(7, 9));
```
I turned Pos into a struct, seems like a typical value type to me.
Re: Is there such a JSON parser?
On Monday, 2 January 2023 at 21:36:10 UTC, Steven Schveighoffer wrote: On 1/1/23 6:28 PM, torhu wrote: I need to parse some JSON data into various data structures, so I'm looking for a parser based on events or ranges. One that doesn't just load the file and build a data structure that represents the whole thing. So not std.json, at least. It's pretty rough-edged, but https://code.dlang.org/packages/jsoniopipe will do this. It has mechanisms to jump to specific object members, and to rewind to a cached point. It does not use any intermediate representation. -Steve Thank, I can check it out.
Re: Handling CheckBox state changes in DLangUI
On Saturday, 31 December 2022 at 02:40:49 UTC, Daren Scot Wilson wrote: The compiler errors I get are, for no '&' and with '&': Error: function `app.checkbox_b_clicked(Widget source, bool checked)` is not callable using argument types `()` Error: none of the overloads of `opAssign` are callable using argument types `(bool function(Widget source, bool checked))` If checkbox_b_clicked is a non-static nested function or non-static method, taking the address of it should result in a delegate, not a function pointer. You can check what it is like this: writeln(typeid(_b_clicked));
Re: Is there such a JSON parser?
On Monday, 2 January 2023 at 14:56:27 UTC, SealabJaster wrote: Are you asking for a SAX-styled parser for JSON? Yes, I actually want to replace a SAX parser.
Re: Is there such a JSON parser?
On Monday, 2 January 2023 at 05:44:33 UTC, thebluepandabear wrote: You might want to try the following: https://github.com/libmir/asdf I had a look at that, but I think it just loads the whole file into it's own data structure. And then you can use attributes to get it to fill structs with data, but that's too basic for my needs.
Is there such a JSON parser?
I need to parse some JSON data into various data structures, so I'm looking for a parser based on events or ranges. One that doesn't just load the file and build a data structure that represents the whole thing. So not std.json, at least.
Re: Release D 2.101.2
On Sunday, 1 January 2023 at 06:52:22 UTC, Iain Buclaw wrote: Glad to announce D 2.101.2, ♥ to the 3 contributors. http://dlang.org/download.html This point release fixes a few issues over 2.101.1, see the changelog for more details. http://dlang.org/changelog/2.101.2.html -Iain on behalf of the Dlang Core Team Thanks, my project builds again after #23499 was fixed!
Re: Release D 2.101.0
On Tuesday, 27 December 2022 at 17:59:11 UTC, Les De Ridder wrote: On Wednesday, 16 November 2022 at 01:13:29 UTC, torhu wrote: On Tuesday, 15 November 2022 at 20:54:03 UTC, Iain Buclaw wrote: Glad to announce D 2.101.0, ♥ to the 63 contributors. For some reason my project build fails with this version, but only the x86 release build. Only tried it on Windows. This is the error, I'll post a bug report if I can narrow it down more: Error C:\prog\dmd\windows\bin\dmd.exe failed with exit code -1073741795. This seems to still be broken in 2.101.1 and is breaking my CI: <https://github.com/lesderid/keynavish/actions/runs/3789010705/jobs/6442404036>. I see the same thing, only the release build, and only x86, fails.
Re: How to use version in dub?
On Tuesday, 13 December 2022 at 19:50:15 UTC, torhu wrote:
On Tuesday, 13 December 2022 at 19:28:44 UTC, Leonardo A wrote:
Hello. How to use version in dub?
https://dlang.org/spec/version.html
"The version level and version identifier can be set on the
command line by the -version"
I tried everything but noting.
In SDL syntax, either at the top level, in a configuration, or
build type:
```
versions "something" "other"
```
To be more clear: When using dub you need to put this in the dub
file, dub.sdl or dub.json. If you want to be able to choose from
the command line, use a configuration:
```
configuration "something" {
versions "something"
}
```
Then you can do:
```
dub build -c=something
```
Re: How to use version in dub?
On Tuesday, 13 December 2022 at 19:28:44 UTC, Leonardo A wrote: Hello. How to use version in dub? https://dlang.org/spec/version.html "The version level and version identifier can be set on the command line by the -version" I tried everything but noting. In SDL syntax, either at the top level, in a configuration, or build type: ``` versions "something" "other" ```
menuDetected not called on right click on table header
I'm trying to add a context menu to a table header, by adding a MenuDetectListener to the Table instance. A right click on the header does not seem to register at all, while clicking on a cell works fine. This is on Windows.
Re: Release D 2.101.0
On Wednesday, 16 November 2022 at 01:21:12 UTC, rikki cattermole wrote: Yeah, you'll want to use dustmite. Hopefully the project isn't too big. I haven't figured out how to use DustMite, but the error goes away when I compile one file at a time, for some reason.
Re: Release D 2.101.0
On Tuesday, 15 November 2022 at 20:54:03 UTC, Iain Buclaw wrote: Glad to announce D 2.101.0, ♥ to the 63 contributors. For some reason my project build fails with this version, but only the x86 release build. Only tried it on Windows. This is the error, I'll post a bug report if I can narrow it down more: Error C:\prog\dmd\windows\bin\dmd.exe failed with exit code -1073741795.
Re: aa.keys, synchronized and shared
On Monday, 14 November 2022 at 07:57:16 UTC, Kagamin wrote:
This works for me:
```
shared SyncAA!(string,string) saa;
void f()
{
saa=new shared SyncAA!(string,string)("1","2");
saa.keys();
saa["12"]="34";
saa.remove("12");
}
```
The strange error message I got was because I initialized the
variable at module level, that doesn't work when you have a
constructor. It worked when I moved it into a module constructor.
Re: aa.keys, synchronized and shared
On Friday, 11 November 2022 at 14:19:31 UTC, Kagamin wrote:
Try this:
```
private:
V[K] sharedTable;
ref inout(V[K]) unsharedTable() inout
{
return *cast(inout(V[K])*)
}
```
Thanks, that worked! Feels like programming in C, though. If I
could figure out how to initialize the AA explicitly, I could
also remove the ref here. If I just remove the ref, the AA is
always null. If I try to initialize it in the constructor, I get
this:
src\syncaa.d(11,5): Error: `_d_monitorenter` cannot be
interpreted at compile time, because it has no available source
code
No idea why, it seems to happen if I try to use the AA in the
constructor at all. Even when I just do `data_.remove(K.init);`
I also tried DMD 2.101.0-rc.1, using the new `new V[K]` syntax,
same error there.
Re: aa.keys, synchronized and shared
On Thursday, 10 November 2022 at 21:55:26 UTC, torhu wrote: I'm trying to make a more thread-safe wrapper for AA's: ``` synchronized final class SyncAA(K, V) /// I chose to fix this by just using `synchronized (this)` inside each method instead, for now. Still interested in cleaner solutions, but I guess synchronized/shared is a bit of a rabbit hole...
aa.keys, synchronized and shared
I'm trying to make a more thread-safe wrapper for AA's:
```
synchronized final class SyncAA(K, V) ///
{
///
V opIndex(K key) { return data_[key]; }
///
V opIndexAssign(V value, K key) { return data_[key] = value; }
///
K[] keys() const { return data_.keys; }
///
void remove(K key) { data_.remove(key); }
/// There is no `in` operator, it would not be thread-safe.
V get(K key, lazy V defaultValue=V.init)
{
auto p = key in data_;
return p ? *p : defaultValue;
}
///
int opApply(scope int delegate(inout ref V) dg) const
{
int result = 0;
foreach (value; data_) {
result = dg(value);
if (result)
break;
}
return result;
}
///
int opApply(scope int delegate(K, inout ref V) dg) const
{
int result = 0;
foreach (key, value; data_) {
result = dg(key, value);
if (result)
break;
}
return result;
}
private:
V[K] data_;
}
```
In another file:
`__gshared serverListCache = new SyncAA!(string, ServerList);`
I'm using `keys` in a regular function, this is the error i get:
C:\prog\dmd\windows\bin\..\..\src\druntime\import\object.d(3245,36): Error:
cannot implicitly convert expression `aa` of type
`shared(const(ServerList[string]))` to `const(shared(ServerList)[string])`
src\syncaa.d(17,36): Error: template instance
`object.keys!(shared(const(ServerList[string])),
shared(const(ServerList)), string)` error instantiating
src\serveractions.d(45,33):instantiated from here:
`SyncAA!(string, ServerList)`
src\serveractions.d(50,17): Error: `shared` `const` method
`syncaa.SyncAA!(string, ServerList).SyncAA.keys` is not callable
using a non-shared mutable object
Error C:\prog\dmd\windows\bin\dmd.exe failed with exit code 1.
Re: Build fails on Linux Mint 21
On Monday, 3 October 2022 at 01:27:23 UTC, torhu wrote: I got it to build by using the 4.7 branch instead. Now I get a segfault at startup, which seems to come from a Display.getDefault() call in a module constructor. Fixed that one. Now I found out that Display.syncExec runs the Runnable in the wrong thread. Anyone got a fix for this issue?
Re: Doubt about char.min/max == typeid(char)
On Friday, 7 October 2022 at 00:13:59 UTC, matheus wrote:
Hi,
Could anyone please tell me why the properties of min/max of a
char returns a "char type" and not a value as an int?
Well, why whould the highest and lowest values of a type be of a
different type..?
```d
import std;
void func(char x) { writeln("It's a char"); }
void func(int x) { writeln("It's an int"); }
void func(double x) { writeln("It's a double"); }
void main(){
func(char.min);
}
```
Re: Replacing tango.text.Ascii.isearch
On Thursday, 6 October 2022 at 21:36:48 UTC, rassoc wrote:
And what kind of testing was that? Mind to share? Because I did
the following real quick and wasn't able to measure a "two
orders of magnitude" difference. Sure, the regex version came
on top, but they were both faster than the ruby baseline I
cooked up.
Originally I just loaded a one megabyte file and searched the
whole thing. I changed it to split it into (40 000) lines
instead, regex is about ten times faster then. I compile with
-release -O -inline. Here is the second version:
```d
import std;
import std.datetime.stopwatch;
enum FILE = "test.lst";
string text;
string needle;
void test(bool delegate(string haystack) dg)
{
auto sw = StopWatch(AutoStart.yes);
int counter = 0;
foreach (line; lineSplitter(text)) {
if (dg(line))
counter++;
}
sw.stop();
writefln("%s", sw.peek());
writefln("counter: %s", counter);
}
void main(char[][] args)
{
enforce(args.length > 1, "Need a needle argument.");
text = cast(string)read(FILE);
needle = args[1].idup;
auto re = regex(to!string(escaper(needle)), "i");
string needleLower = needle.toLower();
test((h) => !!h.matchFirst(re));
test((h) => h.asLowerCase().canFind(needleLower));
}
```
Re: Replacing tango.text.Ascii.isearch
On Wednesday, 5 October 2022 at 17:29:25 UTC, Steven
Schveighoffer wrote:
```d
bool isearch(S1, S2)(S1 haystack, S2 needle)
{
import std.uni;
import std.algorithm;
return haystack.asLowerCase.canFind(needle.asLowerCase);
}
```
untested.
-Steve
I did some basic testing, and regex was two orders of magnitude
faster. So now I know, I guess.
Re: Replacing tango.text.Ascii.isearch
On Wednesday, 5 October 2022 at 20:45:55 UTC, torhu wrote: On Wednesday, 5 October 2022 at 20:40:46 UTC, torhu wrote: Am I doing something wrong here? Right, you can instantiate structs without arguments. It's been ten years since I last used D, I was thinking of structs like if they were classes. I think there should be sensible default here, seems like an easy trap to remove.
Re: Replacing tango.text.Ascii.isearch
On Wednesday, 5 October 2022 at 20:40:46 UTC, torhu wrote: Am I doing something wrong here? Right, you can instantiate structs without arguments. It's been ten years since I last used D, I was thinking of structs like if they were classes.
Re: Replacing tango.text.Ascii.isearch
On Wednesday, 5 October 2022 at 17:29:25 UTC, Steven
Schveighoffer wrote:
[...]
I wanted to do some quick benchmarking to figure out what works.
When I run this:
```d
import std.stdio;
import std.datetime.stopwatch;
void main()
{
auto sw = StopWatch();
sw.stop();
writeln(sw.peek().toString());
}
```
It prints this:
2 weeks, 6 days, 9 hours, 34 minutes, 43 secs, 214 ms, 946 ╬╝s,
and 7 hnsecs
Am I doing something wrong here?
Replacing tango.text.Ascii.isearch
I need a case-insensitive check to see if a string contains another string for a "quick filter" feature. It should preferrably be perceived as instant by the user, and needs to check a few thousand strings in typical cases. Is a regex the best option, or what would you suggest?
Re: Build fails on Linux Mint 21
On Sunday, 2 October 2022 at 22:08:39 UTC, torhu wrote: I am not able to find libgnomeui-dev, maybe that's all that's missing? If anyone has a DWT fork without that dependency, that would be great. I got it to build by using the 4.7 branch instead. Now I get a segfault at startup, which seems to come from a Display.getDefault() call in a module constructor.
Build fails on Linux Mint 21
I get this when trying to do a 64-bit build: Linking... ../../.dub/packages/dwt-1.0.5_swt-3.4.1/dwt/org.eclipse.swt.gtk.linux.x86/src/org/eclipse/swt/program/Program.d:263: error: undefined reference to 'gnome_icon_theme_new' ../../.dub/packages/dwt-1.0.5_swt-3.4.1/dwt/org.eclipse.swt.gtk.linux.x86/src/org/eclipse/swt/program/Program.d:704: error: undefined reference to 'gnome_vfs_init' ../../.dub/packages/dwt-1.0.5_swt-3.4.1/dwt/org.eclipse.swt.gtk.linux.x86/src/org/eclipse/swt/program/Program.d:689: error: undefined reference to 'gnome_icon_lookup' ../../.dub/packages/dwt-1.0.5_swt-3.4.1/dwt/org.eclipse.swt.gtk.linux.x86/src/org/eclipse/swt/program/Program.d:692: error: undefined reference to 'gnome_icon_theme_lookup_icon' collect2: error: ld returned 1 exit status Error: /usr/bin/cc failed with status: 1 /usr/bin/ldc2 failed with exit code 1. I am not able to find libgnomeui-dev, maybe that's all that's missing? If anyone has a DWT fork without that dependency, that would be great.
Re: Template function alias that leaves out the last type parameter
On Wednesday, 28 September 2022 at 12:43:52 UTC, rassoc wrote:
On 9/28/22 02:04, torhu via Digitalmars-d-learn wrote:
Thank you, works like a charm!
It does? How are you formatting `info("foo", 'a', 42)` inside
the template if I may ask?
It works like writefln, so that example would not compile. I
forgot to make the format string explicit, I probably should have
done that.
```
private template _messageBox(string title, int style)
{
void _messageBox(T...)(T args)
{
messageBox(format(args), title, style);
}
}
```
Re: Template function alias that leaves out the last type parameter
On Tuesday, 27 September 2022 at 23:18:06 UTC, Adam D Ruppe wrote: On Tuesday, 27 September 2022 at 22:39:52 UTC, torhu wrote: How would I achieve something like this, do I have to turn the aliases into functions? You can write it out long-form with two steps like this: Thank you, works like a charm!
Re: Template function alias that leaves out the last type parameter
On Tuesday, 27 September 2022 at 22:39:52 UTC, torhu wrote:
How would I achieve something like this, do I have to turn the
aliases into functions?
```d
void _messageBox(string title, int style, T...)(T args)
{
string s = format(args);
/* etc... */
}
alias _messageBox!(APPNAME, SWT.ICON_INFORMATION) info;
alias _messageBox!("Warning", SWT.ICON_WARNING) warning;
alias _messageBox!("Error", SWT.ICON_ERROR) error;
```
I should mention that I am really looking for a Phobos 2 way of
achieving what I currently do, which is this:
```d
void _messageBox(string title, int style)(...)
{
char[] msg;
void f(dchar c) { encode(msg, c); }
doFormat(, _arguments, _argptr);
messageBox(cast(string)msg, title, style);
}
```
Template function alias that leaves out the last type parameter
How would I achieve something like this, do I have to turn the
aliases into functions?
```d
void _messageBox(string title, int style, T...)(T args)
{
string s = format(args);
/* etc... */
}
alias _messageBox!(APPNAME, SWT.ICON_INFORMATION) info;
alias _messageBox!("Warning", SWT.ICON_WARNING) warning;
alias _messageBox!("Error", SWT.ICON_ERROR) error;
```
Looking for master thesis ideas
I'm a master student of informatics looking for ideas for my thesis project. One idea would be implementing type providers for D: https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tutorials/type-providers/ Any comments on that, or suggestions? What could I spend my master on do that would be useful to the D community?
Re: 1st Ever Artificial Consciousness to be Written in D Language
On 02.09.2015 16:41, GrandAxe wrote: This is to inform the D Language community that the first viable general artificial algorithm is being written in D. It is called Organic Big data intelligence (OBI); the website is at www.okeuvo.com. Some of its capabilities are: 1. Ability to learn 2. Ability to analyse 3. Problem solving 4. Moral judgement 5. Ability to feel emotions 6. Free will 7. Consciousness 8. Self awareness Looks like the perfect controller software for my cold fusion powered housekeeper/cook android.
Re: Article: Increasing the D Compiler Speed by Over 75%
On 26.07.2013 01:15, Leandro Lucarella wrote: Walter Bright, el 25 de July a las 14:27 me escribiste: On 7/25/2013 11:49 AM, Dmitry S wrote: I am also confused by the numbers. What I see at the end of the article is 21.56 seconds, and the latest development version does it in 12.19, which is really a 43% improvement. (Which is really great too.) 21.56/12.19 is 1.77, i.e. a 75% improvement in speed. This is certainly misleading, is very easy to be confused with a time reduction of 75%, which one would expect to be 1/4 of the original time. :) A doubling of the speed would be 100%, just saying.
Re: Can we get rid of non-raw write?
On 20.03.2013 15:34, Nick Sabalausky wrote:
Since *at least* as far back as XP, Windows has handled \n newlines
perfectly fine. The command line displays them properly, .BAT scripts
handle them properly, every code editor in existence handles them
properly. The *only* thing I've found that doesn't is Windows Notepad,
but really, whoTF uses that anyway?
So, why are silently and forcefully converting \n to \r\n on
windows by default? All it does is cause bugs. For example:
https://github.com/repeatedly/mustache-d/issues/3
And that's definitely not the first time I've run into problems due
using the write* functions instead of rawWrite.
Consider this straightforward code:
--
import std.file;
import std.stdio;
void transform(string str)
{
/+ ...perform some modification of 'str'... +/
return str;
}
void main()
{
auto str = cast(string) read(args[1]);
str = transform(str);
write(str);
}
--
That simple code is *wrong*:
It works correctly for all input on Unix: Output newlines match input
newlines. Always. The code never asks for newlines to be messed with,
and therefore they never are.
You're mixing binary and text mode functions. read() is binary,
stdout.write() is text mode. And yes, you are asking for newlines to be
messed with, as File.write is documented to write in text mode.
But I agree that the docs need improvement. And maybe the API.
Re: Can we get rid of non-raw write?
On 22.03.2013 00:36, Nick Sabalausky wrote: On Thu, 21 Mar 2013 23:37:06 +0100 torhu no@spam.invalid wrote: You're mixing binary and text mode functions. read() is binary, stdout.write() is text mode. And yes, you are asking for newlines to be messed with, as File.write is documented to write in text mode. But I agree that the docs need improvement. And maybe the API. You're missing the point. The point is that the text mode is bug-prone, grossly obsolete, and completely useless and therefore should absolutely not be the default, *if* it has any reason to even exist at all. Text mode isn't going away, I don't know where you'd get that idea from. I'm sure Microsoft wants Linux to go away, too. If you want a to finance a FUD campaign to hurt the reputation of text mode, be my guest. Or keep on ranting, who's gonna stop you.
Re: Table header not visible - Windows 7
On 16.02.2013 14:01, deed wrote: This example code doesn't render any table headers on Windows 7: You need to link with /Lsu:windows:4 or /Lsu:console:4. That's DMD's command line syntax.
Re: Article: Dispelling Common D Myths
On 10.10.2012 09:06, Jacob Carlborg wrote: On 2012-10-10 08:38, Nick Sabalausky wrote: Some stuff I thought needed to be said and shared: http://semitwist.com/articles/article/view/dispelling-common-d-myths Personally, I would have pointed out that there are some other useful modules in Tango that Phobos still is missing, cryptographic and log related modules. Here are some other things that I can't remember seeing in Phobos 2: - An easy-to-use Process module with piping, etc (Yes, I know it's been in the pipeline for some time.) - A cross platform way of loading dynamic libraries (std.loader always sucked, you had to customize it to actually use it) There could be some others that I'm forgetting. In my view, D2/Phobos2 is still playing catch-up to D1/Tango. The D1 compiler is less buggy, Tango is still better than Phobos2, library could well be better. I wouldn't recommend anyone to start a new project in D1. But I also feel that some people are jumping the gun when they talk about D2's maturity.
Re: Tips for debugging EXC_BAD_ACCESS
On 11.10.2012 08:52, Jacob Carlborg wrote: I didn't have any luck with this in the learn newsgroup so I'm trying here. I'm trying to debug the Mac OS X port of DWT. Almost as soon as a DWT application starts to process events I receive a segmentation fault. The error happens in the objc_msgSend C function when calling an Objective-C method. GDB backtrace: If this is something that worked in D1 but doesn't in D2, it could be just some static member variable that suddenly became thread local. But you probably already thought of that.
Re: D1: Passing 0x00000000 value to a Windows COM function
On 20.08.2012 18:22, jicman wrote:
...
dchar GetSourceLanguageEnumaration(char[] lang)
{
// *** STaggerF.SourceLanguage Enumeration ***
dchar sl = 0x;
lang = std.string.tolower(lang);
//msgBox(lang);
switch(lang)
{
case sq, sq-al: // stfTargetLanguageAlbanian = 0x,
I don't think that will work, try this instead:
case sq: case sq-al:
Re: D1: Passing 0x00000000 value to a Windows COM function
On 20.08.2012 00:43, jicman wrote:
Greetings.
I am trying to pass a (I think) dchar value to a Windows COM
function and it does not work. Imagine this situation...
dchar test()
{
dchar val = 0x;
return val
}
void main()
{
...lots of code excluded
SomeWindowsComCall(test); // this call does not work
SomeWindowsComCall(0x); // this call works
}
Any idea how I can create a function to be able to return values
such as 0x .. 0x?
Returning a dchar works just fine when I try it, there is probably a bug
in your code.
What is the argument type of SomeWindowsComCall? That's the type you
should, and it's probably not a dchar. Look at the MSDN docs for the
function to see what type it wants.
Re: D1: Passing 0x00000000 value to a Windows COM function
On 20.08.2012 00:43, jicman wrote:
Greetings.
I am trying to pass a (I think) dchar value to a Windows COM
function and it does not work. Imagine this situation...
dchar test()
{
dchar val = 0x;
return val
}
void main()
{
...lots of code excluded
SomeWindowsComCall(test); // this call does not work
SomeWindowsComCall(0x); // this call works
}
Any idea how I can create a function to be able to return values
such as 0x .. 0x?
It's easier to help if you post an actual, compilable example. As small
as possible. Because the code you posted doesn't show any real
possibility of bugs, barring compiler bugs.
Re: First working Win64 program!
On 12.08.2012 23:21, Sean Cavanaugh wrote: Post windows 8 launch we should start seeing mainstream games shipping 32 and 64 bit binaries together in the same box. We already have moved off of 32 bit in house for our editors and tools. The biggest hangup is Microsoft keeps shipping 32 bit OSes, and we still have to support XP at least through the end of the year. With a little luck Win8 will be the last 32 bit one. Can I ask, what are the reasons you want to move to 64 bits on the Windows platform? Is it higher memory requirements or something else? The game with the highest memory use I've got installed is AFAIK Starcraft II, still at only about one GB. And as you know, 64 bit apps can have lower performance than 32 bits in some cases. So I'm curious to know what the reasons are in your case.
Re: First working Win64 program!
On 13.08.2012 02:59, Sean Cavanaugh wrote: On 8/12/2012 6:43 PM, torhu wrote: On 12.08.2012 23:21, Sean Cavanaugh wrote: Post windows 8 launch we should start seeing mainstream games shipping 32 and 64 bit binaries together in the same box. We already have moved off of 32 bit in house for our editors and tools. The biggest hangup is Microsoft keeps shipping 32 bit OSes, and we still have to support XP at least through the end of the year. With a little luck Win8 will be the last 32 bit one. Can I ask, what are the reasons you want to move to 64 bits on the Windows platform? Is it higher memory requirements or something else? The game with the highest memory use I've got installed is AFAIK Starcraft II, still at only about one GB. And as you know, 64 bit apps can have lower performance than 32 bits in some cases. So I'm curious to know what the reasons are in your case. 32 bit Windows games are capped at around 1.3 GB due to WinXP support. You can get closer to 1.7 GB of address space out of your 32 bit apps when run under 64 bit windows, but thats about it, without playing with /3GB LARGEADDRESSAWARE flags etc. Games that push 1.3 GB or more run the risk of crashing due to both address space fragmentation and running out of memory from the heap. Ok, so using LARGEADDRESSAWARE doesn't improve the situation on XP 64? What about on Vista 64?
Re: FYI my experience with D' version
On 28.07.2012 22:55, Adam D. Ruppe wrote:
After some experience, I've come to the conclusion that
using D's version() with custom things is usually a mistake.
Not always - I think it is still good for platform like tweaks,
version(X86) or version(Windows), or even version(Custom_Library),
(note, it is often smart to put an else static assert(0) at the
end of platform version lists, so it doesn't pass silently on new
one)
But using it to enable or disable particular named features or
other kind of custom configuration things is a mistake. Every
time I've done it for that, I've gone back and changed it.
The reason is it is too easy to get it wrong:
module a:
version = Foo;
module b:
import a;
version(Foo) { this doesn't actually execute }
version is good for global options that you set with -version on the
command line. And can also be used internally in a module, but doesn't
work across modules. But it seems you have discovered this the hard way
already.
I think there was a discussion about this a few years ago, Walter did it
this way on purpose. Can't remember the details, though.
Re: WinAPI LowLevel Keyboard Hooks
On 19.07.2012 13:45, DLimited wrote: Hello everyone, I had this great idea of writing a Program that intercepts all keyboard presses and modifies them in certain cases. I want to use it as some kind of global makro program to run in the background and for example allow me to easily post unicode smileys. If you don't want make your own program, you can go here instead: http://www.autohotkey.com But you probably knew about it.
Re: You crapper encounter...
On 26.02.2012 01:34, Andrei Alexandrescu wrote: Had a good chuckle: http://buztech.org/read-d-programming-ebooks-lesson-1-getting-started.html Andrei Did they use Google translate to translate it to Chinese and then back again? That's the worst I've ever seen.
Re: Calling Kernel32 functions from D
On 25.02.2012 22:50, Gyron wrote: Hey Guys, i'm thinking about moving from c++ to D, but I cant live without the Kernel32 Functions, so whats the easiest way to use them in D? I mean for example ReadProcessMemory etc. Look at the src\druntime\src\core\sys\windows folder in your DMD installation. The Windows API declarations are there. Some things are missing, but you can just declare that yourself as needed. Most of it is in core.sys.windows.windows, but ReadProcessMemory is declared in core.sys.windows.dbghelp. kernel32.lib is linked by default, so you don't need to do anything else to get it working.
Re: Questions about windows support
On 21.02.2012 18:54, Benjamin Thaut wrote: Am 21.02.2012 04:08, schrieb torhu: On 20.02.2012 22:36, Benjamin Thaut wrote: 2) Will dmd support exporting/importing data symbols from dlls? I know there is a patch that does the data symbol address patching from the runtime but thats a feature that should be supported by the compiler directly in my eyes. Importing data symbols works just fine both in DMD and GDC. At least it did a couple of years ago. Can't remember if I've tried exporting, but I wouldn't be surprised if it worked. You don't need to do anything special to get it working, just use declare the data as 'export extern extern (C)' in your D code. For D2 prefix that with '__gshared'. Not very elegent, but it does work. I tried that but it does not work. For example compiler generatd data symbols like the module info or the vtable don't get exported even if the class is declared as export Also the tls storage does not work with threads across dll boundaries. And a lot of other stuff. I consider dll support working as soon as phobos is a shared dll. I see. I assumed you were talking about linking with DLLs written in C. I've never tried linking with a D DLL, except for maybe a simple test case.
Re: Questions about windows support
On 20.02.2012 22:36, Benjamin Thaut wrote: 2) Will dmd support exporting/importing data symbols from dlls? I know there is a patch that does the data symbol address patching from the runtime but thats a feature that should be supported by the compiler directly in my eyes. Importing data symbols works just fine both in DMD and GDC. At least it did a couple of years ago. Can't remember if I've tried exporting, but I wouldn't be surprised if it worked. You don't need to do anything special to get it working, just use declare the data as 'export extern extern (C)' in your D code. For D2 prefix that with '__gshared'. Not very elegent, but it does work.
Re: Questions about windows support
On 21.02.2012 04:08, torhu wrote: On 20.02.2012 22:36, Benjamin Thaut wrote: 2) Will dmd support exporting/importing data symbols from dlls? I know there is a patch that does the data symbol address patching from the runtime but thats a feature that should be supported by the compiler directly in my eyes. Importing data symbols works just fine both in DMD and GDC. At least it did a couple of years ago. Can't remember if I've tried exporting, but I wouldn't be surprised if it worked. You don't need to do anything special to get it working, just use declare the data as 'export extern extern (C)' in your D code. For D2 prefix that with '__gshared'. Not very elegent, but it does work. I should mention that 'export' also works for importing. It does the job of both '__declspec(dllimport)' and '__declspec(dllexport)'.
Re: D forums now live!
On 15.02.2012 11:55, Vladimir Panteleev wrote: On Wednesday, 15 February 2012 at 00:33:29 UTC, torhu wrote: Nice! One suggestion for improvement: don't change the font size based on the browser window size. I'm not a web programmer, but I'm sure someone here can suggest a better way of setting the font size. [...] May I ask why you don't like the current behavior? The font is a bit too small to read, so I zoom in a bit. Then, when I maximize the browser windows for some reason, the font is suddenly very large. If it was based on screen resolution instead, at least it wouldn't change.
Re: D forums now live!
On 14.02.2012 23:00, Walter Bright wrote: http://forum.dlang.org/ This should replace the old miserable web interface to the forums. Thanks to Vladimir Panteleev for an awesome job writing this! Nice! One suggestion for improvement: don't change the font size based on the browser window size. I'm not a web programmer, but I'm sure someone here can suggest a better way of setting the font size.
Re: Can't the dmd source files finally get a proper C++ file extension?
On 24.01.2012 03:35, Trass3r wrote: It's really annoying. clang++ gives a lot of warnings and IDEs are confused as well. Most compilers have switch a for specifying which language to compile as.
Re: Apparently unsigned types really are necessary
On 22.01.2012 13:49, Jonathan M Davis wrote:
On Sunday, January 22, 2012 13:40:08 Marco Leise wrote:
I heard that in the past, but in my own experience using unsigned data
types, it did not cause any more bugs. OTOH, textual output is more
correct and I find code easier to understand, if it is using the correct
'class' of integers. But this a lot of programmers who don't particularly
like using unsigned types must come from somewhere. Except for existing
bugs in the form of silent under-/overflows that do not appear alarming in
a debugger due to their signedness, I've yet to see a convincing example
of real world code, that I would write this way and is flawed due to the
use of uint instead of int. Or is this like spaces vs. tabs? 'Cause I'm
also a tab user.
Down with tabs! ;)
One issue with unsigned integers right off the bat is for loops.
for(size_t i = a.length; i 0; --i) {}
is not going to work.
That'll work just fine, you probably meant '=' ;)
Re: wxWidgets doxygen binding creation.
On 20.01.2012 23:17, Brad Anderson wrote: I occasionally try to think about what sort of changes would be made to the wxWidgets interface to be more idiomatic to D. Signals come to mind (along with delegates wherever possible). Range-based access to the items in certain containers is something that would be useful (wxWidget's container item accessing is a particularly bad part of its API). Probably use D's date/time functionality rather than wxWidget's (or both). There are some stream classes in wxWidgets which could probably be replaced with a range based interface (which would just serve as an adapter between ranges and the streams). It's a shame D doesn't have named parameters because wxWidget's usage would benefit greatly from them (wxWindow and subclasses of it often have 4 or more default parameters that I often need to specify to get to the one parameter I actually want to set). wxSizer's Add method is confusing enough that they added a named parameter idiom version so you could actually read the method call and figure out what is going on. It's also a great benefit to be able to rely on wxWidgets' available examples and documentation, which might outweigh most benefits you can get by improving or D-ifying the API. Adding more convenient ways of doing things on top of the existing API should be fine, though. DWT doesn't add much on top of SWT, but if I recall correctly, the SWT API is already a lot nicer than wxWidgets.
Re: byKey and byValue: properties or methods?
On 21.01.2012 02:43, Andrei Alexandrescu wrote: A good outcome of this vote might have been the distillation of some simple guidelines, as opposed to enforcing some arbitrary consistency. Apparently the participants in this thread are divided regarding general rules as well as their applicability to this particular case. I think that the people here have two different views of what a property is: 1) Just way to hook up some code to what looks and (mostly) behaves like field access. 2) A property of some object, in a wider sense. Examples of 1) are: Creating a read-only field, or delaying calculating a value until first use and then caching it for future use. An example of 2) would be saying that the set of keys of an AA is a property of that AA. As I see it, the main difference between 1) and 2) is that with the latter you are giving field access (dot) syntax a new logical meaning that it didn't use to have. Which why I'm weary of things like aa.byKey. What is the gain, not having to type parentheses? That's not a lot.
Re: byKey and byValue: properties or methods?
On 17.01.2012 07:48, Andrei Alexandrescu wrote:
I hate I must ask this:
int[string] aa;
foreach (k; aa.byKey) { ... }
or
int[string] aa;
foreach (k; aa.byKey()) { ... }
For it to be a property, I think you should be able to simplify this
example:
---
auto k = aa.byKey;
writeln(k.front);
k.popFront();
writeln(k.front);
---
to this:
---
writeln(k.byKey.front);
k.byKey.popFront();
writeln(k.byKey.front);
---
and get the same result. But my understanding is that you wouldn't, in
which case byKey doesn't sense to me as a property. It creates and
returns a new range object each time you call it, right?
Re: byKey and byValue: properties or methods?
On 19.01.2012 18:19, torhu wrote:
On 17.01.2012 07:48, Andrei Alexandrescu wrote:
I hate I must ask this:
int[string] aa;
foreach (k; aa.byKey) { ... }
or
int[string] aa;
foreach (k; aa.byKey()) { ... }
For it to be a property, I think you should be able to simplify this
example:
---
auto k = aa.byKey;
writeln(k.front);
k.popFront();
writeln(k.front);
---
to this:
---
writeln(k.byKey.front);
k.byKey.popFront();
writeln(k.byKey.front);
---
and get the same result. But my understanding is that you wouldn't, in
which case byKey doesn't sense to me as a property. It creates and
returns a new range object each time you call it, right?
Sorry, I meant this for the second example:
---
writeln(aa.byKey.front);
aa.byKey.popFront();
writeln(aa.byKey.front);
---
Re: byKey and byValue: properties or methods?
On 19.01.2012 18:21, torhu wrote:
On 19.01.2012 18:19, torhu wrote:
On 17.01.2012 07:48, Andrei Alexandrescu wrote:
I hate I must ask this:
int[string] aa;
foreach (k; aa.byKey) { ... }
or
int[string] aa;
foreach (k; aa.byKey()) { ... }
For it to be a property, I think you should be able to simplify this
example:
---
auto k = aa.byKey;
writeln(k.front);
k.popFront();
writeln(k.front);
---
to this:
---
writeln(k.byKey.front);
k.byKey.popFront();
writeln(k.byKey.front);
---
and get the same result. But my understanding is that you wouldn't, in
which case byKey doesn't sense to me as a property. It creates and
returns a new range object each time you call it, right?
Sorry, I meant this for the second example:
---
writeln(aa.byKey.front);
aa.byKey.popFront();
writeln(aa.byKey.front);
---
The reason would be that if it looks like field access, it should behave
like that. People will quickly learn how this works, like they have
gotten used to .dup and similar, but what happens when third-party
libraries start doing it too? It think this is not a good precedence to
set. We already have fields and functions, this would be a third kind,
one that looks like a field but behaves more like a function.
Re: byKey and byValue: properties or methods?
On 19.01.2012 19:17, Steven Schveighoffer wrote: That's like saying this: int[] arr; int l = arr.length; l++; should be the same as this: arr.length++; because it's a property. This is an orthogonal problem. byKey doesn't try to affect the original AA, so the semantics should be the same whether you save a copy or access it in one line. There are no hard-fast rules on what should be properties and what shouldn't. But the rvalue vs lvalue is an orthogonal problem. If the type of byKeys is Range, I would expect to be able to treat it like one. Not like one, then another, then another, then another... ad infinitum.
Re: DMD - Windows
On 06.01.2012 21:02, Adam Wilson wrote: COFF is an absolute requirements when working on Windows, yet DMD doesn't support it. Everything, every programming interface, every application running on x64 Windows is built with COFF, the default output of every other compiler on Windows is COFF, everyone else programming on Windows is expecting COFF. Windows represents the largest OS install base in the world; and yet, Windows based D programmers are told that they have to dig up extremely esoteric tools from the darkest, smelliest, most cobwebbed corners of the Internet, just to be able to interact with the the rest of the Windows world. This situation is simply unacceptable. It's not that bad. Most libraries can be compiled to DLL files, in fact that's often the default. DMD/Optlink can use DLL files created by other tool chains just fine. If an import library in the correct format is not available, just use implib or coffimplib to create one. No problem. Some of the D bindings for C libraries include build scripts for building the library with DMC, to allow for static linking with D programs. Most don't, but you can still get by just fine with the DLL build of the library.
Re: Could we use something better than zip for the dmd package?
On 22.12.2011 20:27, Mirko Pilger wrote: The ftp is not the fastest one and 7z reduces the size by 40%. *+1* on desktop i'm mostly a windows guy and since the days of windows 95 my first step after a clean system setup has been always to install a 3rd party file archiver utility. i remember it was winzip in the beginning, shortly after replaced by winrar. i used those archivers until i discovered a file manager (and norton commander clone) named total commander which supports most common compression formats. instead of the windows explorer i use this piece of software for about a decade now. i haven't known that windows supports the zip format out of the box until i read about it here today! when i take a look at my downloads/dev/ folder (which contains mostly compressed source code) i see a majority of zip archives, followed by tar.gz, bz2 and then 7z. the rar format was once known as the optimum for compressing multimedia files and was and is still used a lot for (illegal) file sharing. however rar is starting to become replaced by 7z in the latter use case and will be the de facto standard for compressing big files (GB) in the near future. i use 7z myself for backups for a couple of years now and if i have the choice i will always download 7z first, in absence look for tgz and choose zip always last if there's nothing else available. yes, i might be old fashioned and i'm pretty aware that both ram and disk space is cheap but shouldn't we (developers and engineers) also be at the forefront to push and introduce new technologies? isn't this even our collective responsibility? choice is good. let's make as much formats as download available as possible and let the user decide. the download statistics might be a surprise for some people. /rant Don't the keyboards on your planet have Shift keys?
Re: List of updated libraries
On 19.12.2011 12:34, Henrik Nordvik wrote: On Mon, Dec 19, 2011 at 8:27 AM, Vladimir Panteleev vladi...@thecybershadow.net wrote: On Monday, 19 December 2011 at 06:03:08 UTC, Henrik Nordvik wrote: There's a page on the wiki: http://prowiki.org/wiki4d/wiki.cgi?AllLibraries That wasn't very updated. I checked a sample of the links, and a lot were dead, from 2003, 2004, 2006 etc. With so many dead project I get the feeling that D is dead. I fact, I have found almost no active projects. Well, it's a wiki... if you have a few minutes of free time, you should edit the page to help future readers. Why are so many libraries abandoned? D - the language without libraries. Why are so many libraries abandoned? This is no different from other languages, it's just that dsource.org makes the dead projects highly visible by showing a complete list of all projects. And there's no activity statistics or anything to show which ones are still active. Imagine how many thousands of dead C and Java projects there are on SourceForge. I would guess that about 99% of all open source projects are dead, it's just that you never hear about them.
Re: Program size, linking matter, and static this()
On 19.12.2011 16:08, Steven Schveighoffer wrote: On Fri, 16 Dec 2011 17:30:44 -0500, torhuno@spam.invalid wrote: On 16.12.2011 22:28, Steven Schveighoffer wrote: In short, dlls will solve the problem, let's work on that instead of shuffling around code. How exactly do they solve the problem? An exe plus a DLL version of the library will usually be larger than just a statically linked exe. The DLL is loaded into memory once. With static linking, it's loaded every time you run an exe. I thought we were talking about distribution sizes, not memory use. But anyway, DLL's won't do a lot as long as people don't have a whole bunch of D programs installed.
Re: List of updated libraries
On 19.12.2011 00:20, Henrik Nordvik wrote: Hi, I am looking for an updated list of D projects or libraries that are actively being maintained. I just wasted several hours getting a library to work which apparently has been abandoned (DSSS/rebuild, last change ~3 years ago.). The list on dsource.org doesn't have any indication of whether the project is active or not. Are there any updated resources for this? I think it is very important to have this information somewhere accessible, so that users are not misinformed about what libraries to use, like I was. Unfortunately, I think you would have to check the commit log and the timeline of dsource projects to know if they are still being maintained. Or ask for recommendations on this newsgroup when you need a library. If you need a build tool, you could check out xfbuild. Or just rdmd (comes with dmd) for simple cases.
Re: 64-bit DMD for windows?
On 17.12.2011 04:26, Trass3r wrote: My girlfriend is interviewing for a job at a major government company here in Norway, and was told that she'd need to use DOS at work. Likely some ancient software that no-one's ever wanted to try and upgrade. What is wrong with this world? ;) DOS software can be more productive, since it's often keyboard-only. It all depends, of course. Might be a FoxPro app or something.
Re: 64-bit DMD for windows?
On 17.12.2011 16:37, Trass3r wrote: DOS software can be more productive, since it's often keyboard-only. How is that different from a Windows console app? From an interface point of view, it's basically the same thing. They both support character graphics (like ncurses). Internally, they wouldn't have anything in common at all.
Re: 64-bit DMD for windows?
On 17.12.2011 17:59, torhu wrote: On 17.12.2011 16:37, Trass3r wrote: DOS software can be more productive, since it's often keyboard-only. How is that different from a Windows console app? From an interface point of view, it's basically the same thing. They both support character graphics (like ncurses). Internally, they wouldn't have anything in common at all. The only commercial application I can think of that runs in the Windows console and uses character graphics is Far Manager. 20 years there were lots of applications like that, but they ran on top of DOS instead of Windows.
Re: 64-bit DMD for windows?
On 17.12.2011 19:05, Andrej Mitrovic wrote: Windows still ships with edit, which has more features than notepad. Heheh. cmd.exe /c edit Makes me wonder what it's for, can you run a Windows server without the GUI?
Re: 64-bit DMD for windows?
On 17.12.2011 18:21, Bane wrote: Trass3r Wrote: DOS software can be more productive, since it's often keyboard-only. How is that different from a Windows console app? No Solitare, Facebook... much more productive! Most likely they're running the DOS app in a window in Windows, but that's a good point.
Re: 64-bit DMD for windows?
On 16.12.2011 00:35, Mehrdad wrote: On 12/15/2011 3:20 PM, Trass3r wrote: dealbreaker - i'd love to use D for my scientific programming, but my datasets often reach several GB... my computer has 16GB and i intend to make use of them. Scientific programming on Windoze? You can't be serious :P lol, that's not even the only issue. 32-bit programs can't show 64-bit dialogs. So Open this file... actually shows the SysWOW64 folder instead of the System32 folder, and there's _no way_ to bypass this unless you build a 64-bit app. Most people are not actually doing scientific programming. And they don't actually need to open an open file dialog to access files that are in the real System32. But if they do, there are several easy solutions.[1] Another reason for needing a 64-bit program on Windows would be if you are creating a shell extension. TortoiseSVN comes in both 32-bit and 64-bit flavors for this reason. People coming from Linux are accustomed to a running only 64-bit programs if they have a 64-bit OS. That's simply because Linux is usually distributed through downloading. To limit the download size, they leave out the 32-bit versions of libraries. Which means you can't actually run 32-bit programs without downloading and installing the packages containing those libraries first. At least that's my understanding. This issue doesn't exist on Windows. Probably not on OS X either, but I'm not too familiar with that system. So when people ask for 64-bit versions without stating why they need it, I always have to ask what features they want that the 32-bit version doesn't have. [1] http://www.ghisler.ch/wiki/index.php/Some_Files_and_Folders_Shown_by_Windows_Explorer_Are_Not_Shown_by_Total_Commander!#Solutions
Re: 64-bit DMD for windows?
On 16.12.2011 10:17, Jacob Carlborg wrote: On 2011-12-16 10:10, torhu wrote: On 16.12.2011 00:35, Mehrdad wrote: On 12/15/2011 3:20 PM, Trass3r wrote: dealbreaker - i'd love to use D for my scientific programming, but my datasets often reach several GB... my computer has 16GB and i intend to make use of them. Scientific programming on Windoze? You can't be serious :P lol, that's not even the only issue. 32-bit programs can't show 64-bit dialogs. So Open this file... actually shows the SysWOW64 folder instead of the System32 folder, and there's _no way_ to bypass this unless you build a 64-bit app. Most people are not actually doing scientific programming. And they don't actually need to open an open file dialog to access files that are in the real System32. But if they do, there are several easy solutions.[1] Another reason for needing a 64-bit program on Windows would be if you are creating a shell extension. TortoiseSVN comes in both 32-bit and 64-bit flavors for this reason. People coming from Linux are accustomed to a running only 64-bit programs if they have a 64-bit OS. That's simply because Linux is usually distributed through downloading. To limit the download size, they leave out the 32-bit versions of libraries. Which means you can't actually run 32-bit programs without downloading and installing the packages containing those libraries first. At least that's my understanding. This issue doesn't exist on Windows. Probably not on OS X either, but I'm not too familiar with that system. Mac OS X has universal binaries, that is, libraries and executables containing code for multiple architectures. All system libraries bundled with the OS are compiled (at least) both for 32 and 64bit. This makes it no problem running either 32 or 64bit applications, the user don't have to know or care. I know that much, but I wasn't sure why they were so keen on having 64 bit versions of apps. Maybe just to accelerate the switch to 64-bits by making it easier for developers to support both. And now they have started to leave things like Carbon behind in 32-bit land. At least you can't say that Apple isn't moving forward.
Re: Program size, linking matter, and static this()
On 16.12.2011 22:28, Steven Schveighoffer wrote: In short, dlls will solve the problem, let's work on that instead of shuffling around code. How exactly do they solve the problem? An exe plus a DLL version of the library will usually be larger than just a statically linked exe.
Re: Program size, linking matter, and static this()
On 17.12.2011 00:34, Sean Kelly wrote: On Dec 16, 2011, at 3:16 PM, Andrei Alexandrescu wrote: On 12/16/11 5:08 PM, Sean Kelly wrote: On Dec 16, 2011, at 1:38 PM, Trass3r wrote: A related issue is phobos being an intermodule dependency monster. A simple hello world pulls in almost 30 modules! This was one of the major motivations for separating druntime from phobos. The last thing anyone wants is for something in runtime to print to the console and end up pulling in 80% of the standard library as a result. Well, right now druntime itself may have become the interdependency knot it once wanted to shun :o). The first place to look would be rt/. I know there's some tool that generates dependency graphs for D. Does Descent do that? Maybe this is the tool you're thinking of: http://www.shfls.org/w/d/dimple/
Re: 64-bit DMD for windows?
On 14.12.2011 12:54, dmd.20.browse...@xoxy.net wrote: Hi, Is there a 64-bit version of DMD for windows? The download page offers only an x86 version. Or am I reading too much into that? Cheers, buk There's not much you would need a 64-bit compiler for on Windows. What are you going to use it for?
Re: D1 to be discontinued on December 31, 2012
On 14.12.2011 14:05, Gour wrote: On Wed, 14 Dec 2011 11:15:58 +0100 Jacob Carlborgd...@me.com wrote: I don't know if all of them are successful but important: Tango, DWT, Minid, Orange, Not to say those are not important, but there are, afaict, falling in the category of D1's ecosystem, not end-user apps. Otoh Tango is ported to D2, Minid has moved to Croc, while DWT Orange have D2 ports. DWT for D2 is not in a usable state yet. I'd assume the same goes for Tango.
Re: D1 to be discontinued on December 31, 2012
On 14.12.2011 22:26, Andrej Mitrovic wrote: On 12/14/11, torhuno@spam.invalid wrote: DWT for D2 is not in a usable state yet. It has a few build issues but most samples work. I've never used it for any projects yet though. It doesn't work for much besides the samples.
Re: D1 to be discontinued on December 31, 2012
On 13.12.2011 08:35, Walter Bright wrote: On 12/12/2011 10:26 PM, Jesse Phillips wrote: On Sun, 11 Dec 2011 22:57:02 +, Jesse Phillips wrote: I haven't used D1 for a long time so I can't claim a bad choice here. Actually I think I can state an opinion here. The two things that stand out in my mind are. * There has been a statement of supporting D1 while it is in use (or at least has a decent number of users). Maybe there aren't any, I don't see replies claiming such. There don't seem to be many anymore. I've got one D1 spare time project that I'm still maintaining. Zero D2 projects, as I tried it and then decided to wait until it has had more time to mature. I'm still using DMD 1.061, since there are very few remaining serious compiler bugs. The compiler has gotten pretty good, so the incentive to upgrade is not very strong. And I rarely need to ask questions about D1, since I've been using it for 5 years now. I have a feeling new users mostly go for D2, only to discover that it's not ready for prime time. Then they just leave, instead of checking out D1. Of course, I'm just guessing.
Re: Fixing const arrays
On 11.12.2011 22:24, Jonathan M Davis wrote: ... It was debated some time ago, and it ended up being a property. The fact that save is an action verb and not a noun automatically disqualifies it as a property IMHO, but it was made into a property, and we're pretty much stuck with it at some point. As far as what the function does, I don't think that it's a problem that it's a property, but it's not named like a property, so the situation with regards to save is not ideal, but it's too late now. I really don't get this. When D has 10,000 programmers using it professionally, it's too late. But now it's more like 5 or 10. And they are all presumably aware that D2 is still undergoing some polish. So are the maybe a few hundred people that are using D for hobby projects. They are early adopters, and they know what that entails. I call bogus on the backwards compatibility argument. There's not a lot to be compatible with at this stage. Not compared to what D2 wants to become. As for Andrei's book using save with the parentheses: If D2 gains traction, I'm sure there will be a second edition of that book. And you already want to have the errata handy when using the book. I don't see what the big deal is, at least not compared to letting this stay in the language forever. save being a property is a stupid inconsistency. It's easy to fix, the cost is relatively low. The people using D2 now are all part of a community that want D to succeed, as am I. It's a change for the better, which I'm sure most current D2 users would agree with. How hard can it be?
Re: Fixing const arrays
On 12.12.2011 15:43, Andrei Alexandrescu wrote: On 12/12/11 6:24 AM, torhu wrote: save being a property is a stupid inconsistency. I'm not so sure. Andrei Why? As far as I can tell, it's inconsistent with what properties are used like in other programming languages. Saving something is an action, which to me is a different concept. If it was called currentState instead, that's what I'd call a property. Making something a property gives it certain connotations that break when it's called 'save'. That you can save the state of the range is a property, if you will. But the action of doing so is not a property. People are going to be surprised when save() doesn't compile. Isn't there something called the principle of least surprise?
Re: Fixing const arrays
On 12.12.2011 16:16, Andrei Alexandrescu wrote: On 12/12/11 9:09 AM, torhu wrote: On 12.12.2011 15:43, Andrei Alexandrescu wrote: On 12/12/11 6:24 AM, torhu wrote: save being a property is a stupid inconsistency. I'm not so sure. Andrei Why? As far as I can tell, it's inconsistent with what properties are used like in other programming languages. Why? Saving something is an action, which to me is a different concept. So if we called .save .state or .current things would be any different? Yes, completely. The whole property concept is basically a naming convention. Except that parentheses are now involved. x = obj.foo(); // do the foo thing, then return something x = obj.bar; // get bar obj.bar = 42; // set bar x = obj.save; // get save... hm, that doesn't sound right If it was called currentState instead, that's what I'd call a property. Ah. So now we're wasting time not on @property (as I'd predicted), but instead on what _names_ are suitable to work with it. I rest my case. Making something a property gives it certain connotations that break when it's called 'save'. That you can save the state of the range is a property, if you will. But the action of doing so is not a property. People are going to be surprised when save() doesn't compile. Isn't there something called the principle of least surprise? I think we should only worry about surprising the uninitiated with how poorly designed the whole @property thing is. I'm not trying to defend @property, I think it adds about as much pain as it does gain. But it's there, and your ranges are using it :)
Re: Fixing const arrays
On 12.12.2011 20:03, Jonathan M Davis wrote:
On Monday, December 12, 2011 09:16:53 Andrei Alexandrescu wrote:
On 12/12/11 9:09 AM, torhu wrote:
On 12.12.2011 15:43, Andrei Alexandrescu wrote:
On 12/12/11 6:24 AM, torhu wrote:
save being a property is a stupid inconsistency.
I'm not so sure.
Andrei
Why? As far as I can tell, it's inconsistent with what properties are
used like in other programming languages.
Why?
Saving something is an action,
which to me is a different concept.
So if we called .save .state or .current things would be any different?
If it was called currentState
instead, that's what I'd call a property.
Ah. So now we're wasting time not on @property (as I'd predicted), but
instead on what _names_ are suitable to work with it. I rest my case.
Making something a property gives it certain connotations that break
when it's called 'save'. That you can save the state of the range is a
property, if you will. But the action of doing so is not a property.
People are going to be surprised when save() doesn't compile. Isn't
there something called the principle of least surprise?
I think we should only worry about surprising the uninitiated with how
poorly designed the whole @property thing is.
A property is essentially an abstraction to treat a function like a member
variable. As such, the naming conventions for a property should be equivalent
to those for a variable - and that generally means nouns. save is not a noun.
It's an action verb. So, yes, I think that it's a completely inappropriate
name for a property. Something ilke state or current _would_ be appropriate
names. However, at this point, I really don't think that it's worth arguing
about.
If I were to change it, I'd probably just make save a function rather than
renaming it, but if we did it, then there would be quite a bit of code that
would have to be changed essentially over an argument over whether save is
valid property name because it's not a noun. And while I _don't_ think that
it's a valid property name, that's getting a bit petty given how much code
would break.
It's actually not 'save' being a noun that's the problem. I just
thought of a counter-example:
---
struct Foo {
// the data
Bar data[];
// save data on shutdown?
@property bool save() { return save_; }
@property bool save(bool shouldShave) { return save_ = shouldSave; }
private:
bool save_;
}
---
Not meant to be a realistic example, but save is fine as a property here.
Re: Fixing const arrays
On 13.12.2011 02:39, Jonathan M Davis wrote:
On Tuesday, December 13, 2011 02:28:29 torhu wrote:
It's actually not 'save' being a noun that's the problem. I just
thought of a counter-example:
--- struct Foo { // the data Bar data[];
// save data on shutdown? @property bool save() { return save_; }
@property bool save(bool shouldShave) { return save_ = shouldSave;
}
private: bool save_; } --- Not meant to be a realistic example, but
save is fine as a property here.
You can pretty much always come up with another function with a
completely different purpose wit the same name.
Personally, the _only_ issue that I have with save is the fact that
it's a property. The name save works well enough, and I can't think
of anything that's better.
Yes, that's my opinion too.
Re: The current status of D?
On 01.12.2011 22:24, Buk wrote: Simple question, though not necessarily a simple answer: Is D ready for prime time? Sub-questions: 1. How stable is the language specification? 2. How stable is the language implementation? 3. How stable are the standard library specifications? 4. How stable are the standard library implantations? The last time I looked was just after the D1/D2 split, and much of the design was being revamped and the rate of changes and deprecations was (IMO) too high to consider its use for complex, multi-developer projects. Looking around the docs here, I see that some of the libraries are due for deprecation early next year. Barring surprises, are they likely to be the last major changes? Thanks for your time, buk. If you want something that's ready for prime time, D1+Tango is what I would recommend. I think D2 is not there yet. The language has gotten a lot more complex, and as a result of that, they are not quite done figuring out how to get all of it to fit together yet. A least that's my impression. I've used D and followed this newsgroup since 2006, so I don't think I'm completely clueless. Some of the new features are not yet implemented, which others have mentioned. As for Phobos 2, I don't know what to think yet. I find it hard to trust that the template-heavy code is fast, that the compiler can reliably optimize all those layers away.
Re: D2 port of xfBuild (alpha version)
On 30.11.2011 08:15, Jacob Carlborg wrote: On 2011-11-29 22:14, torhu wrote: On 29.11.2011 13:20, Jacob Carlborg wrote: On 2011-11-29 12:00, Andrej Mitrovic wrote: FWIW a couple of bugs from the old issue tracker were fixed in the new fork. Bugs were reported here: https://bitbucket.org/h3r3tic/xfbuild/issue/16/xfbuild-crashes-if-full-path-to-deps-objs https://bitbucket.org/h3r3tic/xfbuild/issue/17/xfbuild-crashes-optlink-on-windows-if-o There was also a multithreaded bug that manifested itself on Windows where printing to the console would be interleaved and left the message scrambled. This is now fixed. Also, the +xpath option was added, first discussed here: https://bitbucket.org/h3r3tic/xfbuild/issue/1/add-a-xpath-option I'll have to look into the whole template instantiation fiasco and see where we are at that and if it can be resolved. Stay tuned.. :) https://github.com/AndrejMitrovic/xfbuild Walter mentioned something that if the -lib flag is used it will output templates to all object files. If that was what you were referring to. The -lib flag leads to bloated executables. Maybe the linker doesn't get rid of the duplicates, I don't know. That may be so, but at least the application works, if Walter is correct about the -lib flag. He has also said he doesn't want to add a flag that does what's necessary with the templates. Maybe this is about something else than I was thinking of. I was thinking of the linker errors you will get if you do partial rebuilds. Missing symbols for struct initializers and things like that. And templates too, I guess. Can't remember the details anymore. But the -lib flags wouldn't help with that anyway.
Re: About File.rawWrite
On 29.11.2011 16:00, Denis Shelomovskij wrote: Your OS is Windows, right? On Windows, rawWrite and rawRead always flushes stream, sets binary mode, reads/writes, flushes stream again, sets previous mode. This is definitely unnecessary slow - at least it should change mode only if needed (the file is opened in a text mode). The better solution is to change all other functions so the file mode will be changed lazily (for a text file, raw* functions will change file mode and leave file in this mode until a call of a function, that really needs a file to be in a text mode). By the way, why this changing mode behaviour is Windows only? Yes, it is clearly documented that this is the case, but it isn't documented _why_ this is the case. Text mode means that \n in strings is translated to \r\n when writing, and the other way when reading. That way you can use only LF (\n) to get linefeeds on all platforms, even if Windows uses CRLF.
Re: The future of std.compiler
On 20.11.2011 20:44, Alex Rønne Petersen wrote: Hi, I recently sent some pull requests to move std.compiler into core.compiler. Sean Kelly raised the issue that druntime is very compiler-specific (i.e. GDC and LDC both have their own druntime forks). Given this, having it in druntime probably doesn't make a whole lot of sense. So, the question is, does the module serve any purpose in Phobos? The documentation on version identifiers was updated recently with version identifiers for the various compilers, so detecting different compilers is already trivial. Having encapsulation around version identifiers in Phobos is arguably rather pointless. On the other hand, the module also provides compiler name and version, which I do not believe are defined in all compilers (please correct me if I'm wrong!). What does everyone think? Should we keep this module around or just deprecate it? IIRC, that module was added before __VENDOR__ and __VERSION__ were added to DMD. If it wasn't for that, I suppose it wouldn't even exist.
Re: D:YAML 0.3 released
On 16.11.2011 21:15, Kiith-Sa wrote:
...
GitHub: https://github.com/kiith-sa/D-YAML
Docs : dyaml.alwaysdata.net/docs
You can get D:YAML 0.3 here: https://github.com/kiith-sa/D-YAML/downloads
Great, I've been looking into YAML lately. Would be interesting to see
how the speed of your library compares to Tango's XML parser. Maybe
I'll do some benchmarking.
I think your API could be simplified in some places. I rewrote one of
your examples:
---
bool constructMyStructScalar(ref Node node, out MyStruct result, out
string customError)
{
auto parts = node.as!string().split(:);
try
{
result = MyStruct(to!int(parts[0]), to!int(parts[1]),
to!int(parts[2]));
return true;
}
catch(Exception e)
{
return false;
}
}
---
If the value is invalid, you just return false and let the library take
care of the rest. If you want to give detailed info about the error,
assign to customError. The code calling this function would throw an
exception that contains the standard line and column info, plus your
custom message.
Re: D:YAML 0.3 released
On 17.11.2011 15:01, Kiith-Sa wrote:
Thanks for your input. Your example doesn't seem to be significantly
simpler, but a good point is that the Mark structures don't need to
be passed. I'm considering this style:
---
bool constructMyStructScalar(ref Node node)
{
auto parts = node.as!string().split(:);
try
{
return MyStruct(to!int(parts[0]), to!int(parts[1]), to!int(parts[2]));
}
catch(Exception e)
{
throw SomeExceptionType(message: ~ e.msg); //wrapped by the caller
}
}
---
This would avoid passing the Marks and force the user to specify an
error message.
I'm sorry if I wasn't clear. The main simplification was that I don't
have to throw the exception myself. If all the custom tag handlers are
going to throw the same exception, I think you should not have to write
that code over and over again.
But I think your new example is a good idea, if you change it to this:
---
bool constructMyStructScalar(ref Node node)
{
auto parts = node.as!string().split(:);
return MyStruct(to!int(parts[0]), to!int(parts[1]),
to!int(parts[2]));
}
---
The exception throw by to() could be wrapped in a YAMLException or
whatever, that contains the position information. The toString would
then add the ConvException's error message to the standard YAML error.
If you want a custom message, you could just throw a plain Exception.
I supppose wrapping every call in a try/catch block would have a
negative impact on performance, though.
Re: D:YAML 0.3 released
On 17.11.2011 17:21, Kiith-Sa wrote: Performance is actually not an issue here, insignificant part of total parsing time is spent in Constructor (only about 2%) and any slowdown there should not be noticeable. The idea you're proposing here would indeed simplify the API, but I'm not sure if the result would always be what the user wants. Any exception (potentially user-defined) would be handled and its message added to a YAMLException, as we would need to catch(Exception) in the calling code. I can't think of an example where this could be a problem, since the exceptions we don't expect to be handled are usually derived from Throwable, but what if the user expects an exception to be thrown at MyStruct construction and not handled by D:YAML at all? Do you have an example of what that could be? OutOfMemoryError and things like that would probably go straight through, since they are Errors and not Exceptions.
Re: Phobos examples and auto
On 05.11.2011 20:49, Andrei Alexandrescu wrote: On 11/5/11 1:48 PM, Walter Bright wrote: On 11/5/2011 10:42 AM, Steve Teale wrote: There's a growing tendency in Phobos documentation to use auto. auto now = Clock.currTime(); Now I can understand that when the RHS is some obscure template, whose type might not be immediately obvious, the user should possibly be encouraged to RTFM. But if the outcome is deterministic I just have the feeling that documentation should provide information rather than hiding it. OK, in Jonathan's example, this is preceded by a sentence that says that the result is a SysTime. But the auto made me forget, and wonder what it was, rather than reinforcing the preceding sentence. I realize that this is probably a trivial point, but at the same time, in documentation, clarity is wonderful. I agree. It's tricky. One simple fact that's been verified again and again is that documentation examples tend to be used a lot. They effectively are powerful style influencers for people learning the language. If we avoid auto in documentation examples but we do use it in everyday code, we effectively foster a style that's foreign and non-idiomatic to newcomers. Sample code should mimic real code. If real code would use auto, sample code should use auto. I probably wouldn't use auto in that case. I like having the type explicit, as it saves me from having to spend any effort on remembering what it was. Sometimes the type is too complicated, can vary, or is already mentioned on the right hand side of the expression. Then often find myself using auto. In short, I feel that in this example, auto takes away clarity without adding anything that makes it a net gain.
Re: D2 port of Tango
Great stuff!
Re: Would GIT submodules be a good idea?
On 16.08.2011 18:46, Jacob Carlborg wrote: On 2011-08-16 16:30, Jesse Phillips wrote: It is almost like that. It's just that the cloning also requires the initialization and cloning of the submodules. You'll have to keep them in sync and I've never submoduled a project that had submodules it self. Yeah, I've read that now. I'm not user if there is much point in separating them if you can use dwt- linux or win in something else. But jface could be its own repository as that isn't required to used DWT at all. And making that a submodule is fine. Not all top level directories need to be submodules, that was just a thought. I could include everything to make it possible to build DWT in one repository (the super repository) and have everything else in submodules. What problem is splitting things into submodules supposed to solve? The current Mercurial repository with everything in it is just 50 MB. I suppose Git repositories take up more space, but assume that's not why you want to split things up? If submodules are meant for the same use cases as SVN externals, they are primarily for automatically pulling in stuff that is separate because it is actually a separate project, probably maintained by someone else, or maybe just hosted elsewhere for some reason. Not for splitting a project into parts. Which is why I'm wondering what exactly you want to achieve here.
Re: Move DWT2 repository - github or bitbucket?
On 15.08.2011 15:28, Denis Shelomovskij wrote: 15.08.2011 9:29, Jacob Carlborg: On 2011-08-14 22:20, torhu wrote: On 11.08.2011 19:58, Jacob Carlborg wrote: I'm planning to move the DWT2 repository to either github or bitbucket. Which one would you prefer? Git seems to require a Unix shell to work on Windows. Which is one of the things that make me think that git and Windows is not a match made in heaven. It's a bit like having a crossplatform project that uses Microsoft's C++ extensions, and requires linux contributors to run MSVC through Wine to be able to build it. In other words, I would prefer Bitbucket. But I don't expect to make big contributions, so it's not going to matter much for the project. I have been thinking the same myself. I just haven't figured out how much of a problem it really is. Sorry, but I don't see the problem. There is TortoiseGit with very good Windows explorer integration: http://code.google.com/p/tortoisegit/ And, AFAIK, it's an official git Windows GUI at Download Git section: http://git-scm.com/ Some of us don't want to install yet another shell extension. And I prefer working on the command line, much quicker and simpler.
Re: Move DWT2 repository - github or bitbucket?
On 15.08.2011 08:29, Jacob Carlborg wrote: On 2011-08-14 22:20, torhu wrote: On 11.08.2011 19:58, Jacob Carlborg wrote: I'm planning to move the DWT2 repository to either github or bitbucket. Which one would you prefer? Git seems to require a Unix shell to work on Windows. Which is one of the things that make me think that git and Windows is not a match made in heaven. It's a bit like having a crossplatform project that uses Microsoft's C++ extensions, and requires linux contributors to run MSVC through Wine to be able to build it. In other words, I would prefer Bitbucket. But I don't expect to make big contributions, so it's not going to matter much for the project. I have been thinking the same myself. I just haven't figured out how much of a problem it really is. I thought I'd give hg-git a go, I found an easy way to install it here: http://stackoverflow.com/questions/2360944/how-do-i-correctly-install-dulwich-to-get-hg-git-working-on-windows/6998710#6998710 I cloned one of the Phobos clones on github and played around with it a bit. Works great so far, everything seems to work. Not tried to push or check in, but I suppose it would work just fine. One of Mercurial's strengths is really how easy Python makes it to create extensions and tools.
Re: Symbol undefined due to import statement
On 15.08.2011 10:15, Andre wrote: ... I compile the application with command: dmd -IC:\Projects\Reusuable main.d This works, but if I now edit the http.d file and add an import statement like import std.stdio; then the linker will output following error: main.obj(main) Error 42: Symbol Undefined _D3net4http12__ModuleInfoZ Where is my error? You need to add all your project's files to the command line: dmd -IC:\Projects\Reusuable main.d net\http.d
Re: Replacing hex values in a string (v1.0)
On 12.08.2011 18:19, jicman wrote: Greetings and salutations. Hi. I am reading a file into a string, char[] text = cast(string) f0.read(); and I want to replace every non-breaking space in the string. I know that the hex value for that is A0, but when I do this call, text = std.string.replace(text,xA0, ); It does takes it out, but it adds (or leaves) a little square to it. Apparently, it leaves something else, there. It would be nice if std.string had a function to go from hex to decimal and back. Any ideas? Is the file UTF-8? In that case, try \u00A0 instead, as A0 won't be correct then.
Re: DWT2 now looks working on Windows (except Text widget doesn't support UTF-8)
On 10.08.2011 21:32, Jacob Carlborg wrote: On 2011-08-03 22:02, Denis Shelomovskij wrote: About month ago I fixed some DWT2 bugs, but DWT maintainers just have no time to pull changes to the main repo. Changes are in my (denis_sh) commits descriptions: https://bitbucket.org/denis_sh/patching-dwt2 Short changes description: 1. DWT2 now works on Linux32 with Phobos/D2 as bad as with Tango/D1 (not worse): lots of segfaults when printing and text editing and other bugs. 2. It looks working stable on Windows except Text widget sill doesn't support UTF-8 (yes, StyledText and it's friend now support it). 3. It now have compilable and right snippets. I've pulled your changes now. Thanks so much for your help. I can see now that a almost all snippets work. Only two crash on launch. I've not verified that all the others are working 100% correctly but it's looking really good. You've done a great job. And again, I'm so sorry it took me so long before I pulled the changes. Nice to see work being done on DWT! I did notice a slight problem with changeset 121, though. The array in isDigit needs to be declared static, or it will be copied onto the heap on each call of the function. And the rest of the function could be just this line, simpler and more efficent: return c = '0' c = '9' || assumeSorted(unicodeNd).contains(c); Took me a while to find assumeSorted, but it is in std.range.
Re: Std.path: Final Vote
On 05.08.2011 15:26, dsimcha wrote: My apologies for not announcing this yesterday. For some reason I thought today was the official end of review. Anyhow, Lars Kyllingstad's new std.path module, which has been in review for the past 3 weeks, is up for vote. Please vote yes or no in this thread. Code: https://github.com/kyllingstad/phobos/blob/std-path/std/path.d Docs http://www.kyllingen.net/code/std-path/phobos-prerelease/std_path.html Voting ends next Friday, August 12, since it started a day late. Yes.
