Re: rawCopy, rawTransfer, rawFind ?
On Friday, 26 October 2012 at 21:25:22 UTC, Dmitry Olshansky wrote: Finally got to this: http://d.puremagic.com/issues/show_bug.cgi?id=8349 Half way through it become obvious to me that we'll have similar problems with memcpy and it's ilk every time somebody optimizes bit-wise copy/move/find. More then that I think that we lack a specific set of low-level functions that cover all of C's mem* functionality. (The focus is on fast primitives.) Currently there are obvious gaps: memset ---> cast(ubyte[]) + array ops memcpy ---> cast(ubyte[]) + array ops (also breaks with overlap) ...so far so good... memmove ---> ??? memchr ---> cast(ubyte[]) + std.algorithm.find is *not* good enough (in fact std.algorithm.find arguably could use memchr to greatly optimize some specializations (!) ) Why don't we just use C's ones? a) CTFE-ability, alternatively we can just hard wire all of common libc functions into CTFE b) more generality and/or flexibility, e.g. despite it's speed memchr can't search for ushort or uint c) safer, as it would operate on slices of _typed_ arrays, not pointer + number of _bytes_ So I propose the following set of low-level tools for inclusion into Phobos or druntime: @system: //bitblit, doesn't call destructors/postblits //also can be used to forcibly move structs void rawCopy(T)(const(T) src, T dest); //same, but also works with overlapped memory chunks void rawTransfer(T)(const(T) src, T dest); //fast search, bitwise comparison only void rawFind(T)(const(T)[] src, const(T) needle); Well the above is a sketch. Maybe I'm digging in the wrong direction and this stuff just needs to be somewhere among compiler's intrinsics. (so that it can do some magic if the size is known in advance etc.) These should definitely be put into the language!! but they'd have to be 100% reliable for me to adopt them over C equivalents. unit std.memory anyone?
Re: Simple implementation of __FUNCTION
On Saturday, 3 November 2012 at 17:04:31 UTC, Rob T wrote: On Saturday, 3 November 2012 at 11:09:48 UTC, Jacob Carlborg wrote: I think it would be worth to but in Phobos anyway. I suppose it works as a temp solution until a real one is finally implemented, or maybe the mixin behaviour is considered a bug and can be fixed? I think __FUNCTION__ should be built into the compiler, with it's brothers __FILE__ and __LINE__ . This kinda thing is so useful while debugging and logging :)
Re: [ ArgumentList ] vs. @( ArgumentList )
On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote: For User Defined Attributes. In the north corner we have the current champon: --- [ ArgumentList ] Pros: precedent with C# looks nice Cons: not so greppable parsing ambiguity with [array literal].func(); -- In the south corner, there's the challenger: @( ArgumentList ) Pros: looks like existing @attribute syntax no parsing problems Cons: not as nice looking -- No hitting below the belt! Let the games begin! At first I liked the C# style, but it just does not mix well with D's system attributes. So my vote is for.. @( ArgumentList ) I would prefer if I could enclose system and user attributes in the parenthesis, with no idea how that would work though.
Re: WinAPI for druntime and OpenGL for deimos.
Gor your doing a great job the sooner WindowsApi merges with druntime the better! On Saturday, 24 November 2012 at 22:11:04 UTC, Gor Gyolchanyan wrote: I suggest refactoring other core.sys..* like this. On Sun, Nov 25, 2012 at 2:04 AM, David Nadlinger wrote: On Saturday, 24 November 2012 at 21:54:57 UTC, Gor Gyolchanyan wrote: How about core.sys.windows.c.* ? There is a certain asymmetry in the current state of druntime already: For all the other OSes, core.sys.xyz direclty contains headers for the system libraries, whereas the modules in core.sys.windows actually contain D code. David
Does D have a Queue and Stack container?
As per title, it would be awesome if someone could link me to these. I'm quite suprised that D does not already contain these.. are there any plans for them joining Phobos?
core.thread sleep(long period)
Scheduled for depreciation December 2012? as this been overlooked or is it not depreciated anymore? core.thread static void sleep(long period);
Re: Structs, the most buggiest language feature?
On Wednesday, 11 July 2012 at 07:52:40 UTC, Benjamin Thaut wrote: I wanted to suggest that one developement cycle is spend on fixing as many of the struct connected bugs as possible. Structs are a really important language feature that also often is supposed to be used as a replacement for deperecated features (scope, typedef, ...) Agreed, structs are about as fundamental as basic types are! And if these are left unfixed the language just breaks apart.
Re: Just where has this language gone wrong?
On Thursday, 19 July 2012 at 22:32:04 UTC, David Piepgrass wrote: I suspect that you have a C++ background. If this is not accurate, ignore the rest. But if it is accurate, my plea to you is: Learn other languages. C++ has next to no innovative language features (even C++11's take on lambdas is an abomination) and encourages defensive programming to the point where it's ridiculous (I mean, no default initialization of variables? In 2012?). Actually, C# has no default initialization* of local variables, and I love it. Instead, it is a compile-time error to read a variable if the compiler cannot guarantee that you have initialized it. IMO this is much better than D's "let's initialize doubles to NaN so that something fishy will happen at runtime if you forget to initialize it" :) * technically the compiler asks the runtime to bitwise 0-fill everything, but that's just an implementation detail required for the .NET verifier, and the optimizer can ignore the request to preinitialize. It would be great if D did do this, surely it would not be all that difficult! and wouldn't it also help in finding unused variables?
std.loader; depreciated and removed for 2.060
Are there any plans to provide an alternative solution in Phobos, now that it's been removed?
Re: windows .lib files (dmc has them, dmd doesn't)
On Sunday, 18 August 2013 at 14:53:25 UTC, Andrej Mitrovic wrote: On Sunday, 18 August 2013 at 14:51:52 UTC, Adam D. Ruppe wrote: Can we get some more .lib files with the dmd distribution? And also update the old ones: http://d.puremagic.com/issues/show_bug.cgi?id=6625 This should really take precedence.
cmp and icmp.
Why don't these functions take a length parameter, like strcmp and memcmp? Is it worth making an enhancement request for such?
Re: cmp and icmp.
On Thursday, 4 July 2013 at 22:02:06 UTC, bearophile wrote:
Damian:
Why don't these functions take a length parameter, like strcmp
and memcmp?
Is it worth making an enhancement request for such?
Probably slicing of their inputs, or using std.range.take() of
their inputs, is enough. Do you agree?
Bye,
bearophile
Ah but with slicing the inputs, you must check the length first
so that you don't get an out of bounds error. I would prefer it
if cmp
did this for me, since it is going to check lengths anyway.
Example below.
private void ParsePacket(in char[] data)
{
static string Good = "GOOD";
static string Bad = "BAD";
if (data.length >= Good.length) // Prefer not to do this check
{
if (std.algorithm.cmp(data[0 .. Good.length], Good) == 0)
}
else if
{
// Check Bad, and so on
}
}
Re: cmp and icmp.
On Thursday, 4 July 2013 at 23:10:12 UTC, Jonathan M Davis wrote: On Friday, July 05, 2013 00:36:02 Damian wrote: On Thursday, 4 July 2013 at 22:02:06 UTC, bearophile wrote: > Damian: >> Why don't these functions take a length parameter, like >> strcmp >> and memcmp? >> Is it worth making an enhancement request for such? > > Probably slicing of their inputs, or using std.range.take() > of > their inputs, is enough. Do you agree? > > Bye, > bearophile Ah but with slicing the inputs, you must check the length first so that you don't get an out of bounds error. I would prefer it if cmp did this for me, since it is going to check lengths anyway. Except that cmp doesn't check the length. It just keeps popping elements until one of the two ranges is empty. Taking a length which it had to check would make it _less_ efficient, not more. The correct thing to do here is indeed to slice the range if it can be sliced or to use take if it can't be sliced. And if you want to slice the range and are worried about length, then just use min to make sure that you don't pass a length which is too large. - Jonathan M Davis In the example I gave startsWith is fine, but I also need case insensitive comparison, take and icmp, however, does seem to fit the bill perfectly.
Re: Bug: Crash: nested interfaces
On Saturday, 13 July 2013 at 15:33:31 UTC, JS wrote:
module main;
import std.stdio, std.cstream;
interface A : A.B
{
interface B { }
}
int main(string[] argv)
{
return 0;
}
One can argue about the validity of the code, I tried it to
created logical heirarchy of interfaces.
e.g., instead of interface Name : NameExtension; interface
NameExtension; I wanted Name.Extension for NameExtension. This
would make it easier logically nest interfaces(it would be
better to not use "." though).
In any case, regardless, it causes dmd 2.062 to crash.
In Git head it no longer crashes instead a compilation error,
Error: no property 'B' for type 'main.A'
Re: std.signals regressions
On Friday, 12 July 2013 at 22:35:06 UTC, David wrote:
Am 12.07.2013 23:47, schrieb Robert:
I just finished a new implementation, replacing the template
mixin with
a string mixin. I also changed the name from signals2 to
signal. You can
find it here:
https://github.com/phobos-x/phobosx/blob/master/source/phobosx/signal.d
All unittests pass, you don't need any patched compiler. I
still have to
add some more checks and do some polishing, I will also put it
in the
dub registry. But you seem to have an urgent need, so feel
free to try
it out immediately - Be my pre-alpha Tester :-)
Best regards,
Robert
Bad timing, just got "our"[1] own implementation.
If I have time, I'll play around with it! Thanks for the great
work,
maybe we can get something working into phobos...
[1]https://github.com/AndrejMitrovic/new_signals
Having tried this I can't get ref parameters to work as function
arguments, are they supported?
Example:
struct KeyEvent {}
public Signal!(ref KeyEvent) onKeyDown;
connect, emit ...
public void keyDownHandler(ref KeyEvent keyEvent) { }
Works fine without ref.
Re: working on the dlang.org website
On Tuesday, 30 July 2013 at 16:18:38 UTC, Kagamin wrote: Anybody gets a timeout in hyphenate.js on http://dlang.org/phobos/core_memory.html ? A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete. Script: http://dlang.org/js/hyphenate.js:55 Working fine with Chrome 28.
Re: D1 to be discontinued on December 31, 2012
On Saturday, 10 December 2011 at 21:19:02 UTC, Andrei Alexandrescu wrote: Hello everyone, With all respect to you Andrei, you had no input in D1, I thought that if D1 support will be ever dropped, Walter will announce it. Well... In my humble opinion D1 community is still active. Assuming that nobody uses it is wrong. Walter, thanks for good job on it! I will still stick to it for any serious project (non-hobby ones). I wish you good luck with bringing D2 stable. I just hope I will see such official news from you. Best regards, Damian Ziemba
Re: CURL Wrapper: Vote Thread
Yes
Re: Feq questions about the D language
On Saturday, 10 March 2012 at 12:43:20 UTC, DFGH wrote: I'm a C# programmer who wants to start using D as well for various reasons. Is the official D compiler(DMD) matured enough to be used for writing 'heavy' applications? I mean, there is a bug tracker section for the compiler on this website and there are many 'major' and 'critical' bugs listed there and i'm not sure how much should i be concerned about them. I played with D for a while and it feels a lot like C# which is obviously good for me. What about performance? Yeah, i know that D is a native language and theoretically should be faster than C#, but it's all about compiler/runtime implementations. The Microsoft's .NET implementation nowadays produces extremely fast code. So, performance is definetely NOT one of the reasons for using D. Achieving similar performance in D compared to C# would be good enough for me. Also i need a portable graphic library for drawing 2D primitives. In C# there is a .NET wrapper around GDI+(System.Drawing namespace) and it's super easy to draw things. I have a large GUI application written in C# and i want to rewrite it in D. Is there something like the System.Drawing available? I don't need a heavy framework/api that's used for drawing UI elements(buttons, panels, etc.) like QT, GTK+ or something like that, but a library for drawing primitive objects on the screen. I have drawn almost all the controls in my application using System.Drawing because i'm not happy with some of the built-in controls offered by .NET(which also have some bugs). So, do you know such library? Hello and welcome on board. I've written 3 paid projects in D and couple hobby ones and as far I am very happy with D. Maybe I'm just lucky but I hited only 4 bugs in my "carrier" which one is already fixed. Maybe I haven't wrote enough code in D, well, my biggest project in D is 35K LOC, its webserver solution. I need to say that it scales very well and handles high traffic without any problem. Its up for more than month now and I had only one segfault because of hole in my framework. The only problem actually I have is lack of up-to-date wxD or QtD bindings. 4 GUI applications written with GtkD - they work quite well, but meh, it doesn't work too well on Mac OSX :p I would give it a try. Best regards, Damian Ziemba
Re: How about colors and terminal graphics in std.format?
On Monday, 12 March 2012 at 02:52:15 UTC, Andrei Alexandrescu wrote: On 3/11/12 9:16 PM, Chad J wrote: I remember doing colored terminal output in Python. It was pretty nifty, and allows for some slick CLI design. I think D can do better by putting it in the standard library. I was thinking something along the lines of this: http://www.chadjoan.com/d/dmd.2.058/html/d/phobos/std_format.html I figure it would probably be easy to get some of the basics down. More advanced stuff would probably involve messing with terminfo or . Windows' (terribly bad) command prompt can have some of these capabilities implemented too, but in a roundabout way because Windows defines API functions that need to be called to affect terminal graphics and coloring. I figure that would require the help of the I/O routines if I were to work on that. If there's interest, I might take a stab at it. So, would this sort of thing make it in? I don't know, seems interesting but I wonder how portable that could be. Probably I'd define a more general means a la %q to mean "send a control sequence" and then would define control sequences as functions or constants. Oh, on an unrelated note, Phobos' documentation make target is quite broken: blahblah/dmd.git/src/phobos $ make -fposix.mak html make: *** No rule to make target `../web/phobos-prerelease/index.html', needed by `html'. Stop. I examined the makefile and concocted this line of bash that constructs my desired html file: dmd -m32 -d -c -o- -version=StdDdoc -I../druntime/import std/format.d std.ddoc -Dfstd_format.html and copied std.ddoc from a release version of dmd (it's in src/phobos). Since recently the Phobos doc build is meant to be driven from the site build. I'll fix the standalone thing because it's useful too, just I don't know when. Andrei Some basic stuff like Colors can be portable. I can share my work if somebody is interested. Best regards, Damian Ziemba
Re: How about colors and terminal graphics in std.format?
On Monday, 12 March 2012 at 02:52:15 UTC, Andrei Alexandrescu
wrote:
On 3/11/12 9:16 PM, Chad J wrote:
I remember doing colored terminal output in Python. It was
pretty nifty,
and allows for some slick CLI design. I think D can do better
by putting
it in the standard library.
I was thinking something along the lines of this:
http://www.chadjoan.com/d/dmd.2.058/html/d/phobos/std_format.html
I figure it would probably be easy to get some of the basics
down. More
advanced stuff would probably involve messing with terminfo or
.
Windows' (terribly bad) command prompt can have some of these
capabilities implemented too, but in a roundabout way because
Windows
defines API functions that need to be called to affect
terminal graphics
and coloring. I figure that would require the help of the I/O
routines
if I were to work on that.
If there's interest, I might take a stab at it.
So, would this sort of thing make it in?
I don't know, seems interesting but I wonder how portable that
could be. Probably I'd define a more general means a la %q to
mean "send a control sequence" and then would define control
sequences as functions or constants.
Oh, on an unrelated note, Phobos' documentation make target is
quite
broken:
blahblah/dmd.git/src/phobos $ make -fposix.mak html
make: *** No rule to make target
`../web/phobos-prerelease/index.html',
needed by `html'. Stop.
I examined the makefile and concocted this line of bash that
constructs
my desired html file:
dmd -m32 -d -c -o- -version=StdDdoc -I../druntime/import
std/format.d
std.ddoc -Dfstd_format.html
and copied std.ddoc from a release version of dmd (it's in
src/phobos).
Since recently the Phobos doc build is meant to be driven from
the site build. I'll fix the standalone thing because it's
useful too, just I don't know when.
Andrei
It could work.
In my small framework I use version blocks and I use ansi escape
sequences for posix and SetConsoleTextAttribute for windoze.
Ofcourse there would be a need to create unified enumeration with
colors as they differ on those platforms too.
public enum Font
{
Normal = 0,
Underline = 0x8000,
Reverse = 0x4000,
}
public enum Color
{
Default = 0x,
Blue = 0x0001,
Green = 0x0002,
Aqua = 0x0003,
Red = 0x0004,
Purple= 0x0005,
Yellow= 0x0006,
Gray = 0x0008,
LightBlue = 0x0009,
LightGreen = 0x000A,
LightAqua = 0x000B,
LightRed = 0x000C,
LightPurple= 0x000D,
}
Those are colors and font-attributes that I found to match both
Windows and Posix
Re: How about colors and terminal graphics in std.format?
On Monday, 12 March 2012 at 03:27:41 UTC, Damian Ziemba wrote:
On Monday, 12 March 2012 at 02:52:15 UTC, Andrei Alexandrescu
wrote:
On 3/11/12 9:16 PM, Chad J wrote:
I remember doing colored terminal output in Python. It was
pretty nifty,
and allows for some slick CLI design. I think D can do better
by putting
it in the standard library.
I was thinking something along the lines of this:
http://www.chadjoan.com/d/dmd.2.058/html/d/phobos/std_format.html
I figure it would probably be easy to get some of the basics
down. More
advanced stuff would probably involve messing with terminfo
or .
Windows' (terribly bad) command prompt can have some of these
capabilities implemented too, but in a roundabout way because
Windows
defines API functions that need to be called to affect
terminal graphics
and coloring. I figure that would require the help of the I/O
routines
if I were to work on that.
If there's interest, I might take a stab at it.
So, would this sort of thing make it in?
I don't know, seems interesting but I wonder how portable that
could be. Probably I'd define a more general means a la %q to
mean "send a control sequence" and then would define control
sequences as functions or constants.
Oh, on an unrelated note, Phobos' documentation make target
is quite
broken:
blahblah/dmd.git/src/phobos $ make -fposix.mak html
make: *** No rule to make target
`../web/phobos-prerelease/index.html',
needed by `html'. Stop.
I examined the makefile and concocted this line of bash that
constructs
my desired html file:
dmd -m32 -d -c -o- -version=StdDdoc -I../druntime/import
std/format.d
std.ddoc -Dfstd_format.html
and copied std.ddoc from a release version of dmd (it's in
src/phobos).
Since recently the Phobos doc build is meant to be driven from
the site build. I'll fix the standalone thing because it's
useful too, just I don't know when.
Andrei
It could work.
In my small framework I use version blocks and I use ansi
escape sequences for posix and SetConsoleTextAttribute for
windoze.
Ofcourse there would be a need to create unified enumeration
with colors as they differ on those platforms too.
public enum Font
{
Normal = 0,
Underline = 0x8000,
Reverse = 0x4000,
}
public enum Color
{
Default = 0x,
Blue = 0x0001,
Green = 0x0002,
Aqua = 0x0003,
Red = 0x0004,
Purple= 0x0005,
Yellow= 0x0006,
Gray = 0x0008,
LightBlue = 0x0009,
LightGreen = 0x000A,
LightAqua = 0x000B,
LightRed = 0x000C,
LightPurple= 0x000D,
}
Those are colors and font-attributes that I found to match both
Windows and Posix
Those numbers are for Windows btw :p
Re: How about colors and terminal graphics in std.format?
On Monday, 12 March 2012 at 03:32:26 UTC, Chad J wrote:
On 03/11/2012 11:27 PM, Damian Ziemba wrote:
On Monday, 12 March 2012 at 02:52:15 UTC, Andrei Alexandrescu
wrote:
On 3/11/12 9:16 PM, Chad J wrote:
I remember doing colored terminal output in Python. It was
pretty nifty,
and allows for some slick CLI design. I think D can do
better by putting
it in the standard library.
...
So, would this sort of thing make it in?
I don't know, seems interesting but I wonder how portable
that could
be. Probably I'd define a more general means a la %q to mean
"send a
control sequence" and then would define control sequences as
functions
or constants.
...
Andrei
It could work.
In my small framework I use version blocks and I use ansi
escape
sequences for posix and SetConsoleTextAttribute for windoze.
Ofcourse there would be a need to create unified enumeration
with colors
as they differ on those platforms too.
Good catch.
public enum Font
{
Normal = 0,
Underline = 0x8000,
Reverse = 0x4000,
}
public enum Color
{
Default = 0x,
Blue = 0x0001,
Green = 0x0002,
Aqua = 0x0003,
Red = 0x0004,
Purple= 0x0005,
Yellow= 0x0006,
Gray = 0x0008,
LightBlue = 0x0009,
LightGreen = 0x000A,
LightAqua = 0x000B,
LightRed = 0x000C,
LightPurple= 0x000D,
}
Those are colors and font-attributes that I found to match
both Windows
and Posix
If you can show me you're work and it's licensed in a way that
I can use it in Phobos, then I'll happily try to make use of
it. It'd be much appreciated.
Sure, give me some time and I will prepare code.
Framework is BSD licensed but I can relicense it to whatever you
want.
Re: How about colors and terminal graphics in std.format?
On Monday, 12 March 2012 at 03:32:26 UTC, Chad J wrote:
On 03/11/2012 11:27 PM, Damian Ziemba wrote:
On Monday, 12 March 2012 at 02:52:15 UTC, Andrei Alexandrescu
wrote:
On 3/11/12 9:16 PM, Chad J wrote:
I remember doing colored terminal output in Python. It was
pretty nifty,
and allows for some slick CLI design. I think D can do
better by putting
it in the standard library.
...
So, would this sort of thing make it in?
I don't know, seems interesting but I wonder how portable
that could
be. Probably I'd define a more general means a la %q to mean
"send a
control sequence" and then would define control sequences as
functions
or constants.
...
Andrei
It could work.
In my small framework I use version blocks and I use ansi
escape
sequences for posix and SetConsoleTextAttribute for windoze.
Ofcourse there would be a need to create unified enumeration
with colors
as they differ on those platforms too.
Good catch.
public enum Font
{
Normal = 0,
Underline = 0x8000,
Reverse = 0x4000,
}
public enum Color
{
Default = 0x,
Blue = 0x0001,
Green = 0x0002,
Aqua = 0x0003,
Red = 0x0004,
Purple= 0x0005,
Yellow= 0x0006,
Gray = 0x0008,
LightBlue = 0x0009,
LightGreen = 0x000A,
LightAqua = 0x000B,
LightRed = 0x000C,
LightPurple= 0x000D,
}
Those are colors and font-attributes that I found to match
both Windows
and Posix
If you can show me you're work and it's licensed in a way that
I can use it in Phobos, then I'll happily try to make use of
it. It'd be much appreciated.
Hey Chad.
Sorry for delay, been a bit busy.
Here it is: https://gist.github.com/2025473
I hope it can help you somehow.
(There is place for improvments I know but I used it mostly for
debbuging stuff ;))
And yea, I think like others that it should have its own module
like std.terminal/std.console or maybe somekind of spot in
std.stdio.
Best Regards,
Damian Ziemba
Re: How about colors and terminal graphics in std.format?
On Tuesday, 13 March 2012 at 00:24:58 UTC, Kevin Cox wrote: On Mar 12, 2012 7:55 PM, "Damian Ziemba" wrote And yea, I think like others that it should have its own module like std.terminal/std.console or maybe somekind of spot in std.stdio. Python has a great lib for this. I can't remember what package it is in but it has things like isTty() and all of the colors as well ad querying for different color support. For a name may I recommend std.term. Urwid? Well there are Ncurses bindings lying around, but I guess the point is to get something rather simple. Ofcourse porting for example Urwid from Python to D would be possible but I am not sure if there is a point in doing so. In my framework I've added only stuff that I missed from MS Class Library, and actually were useful, like Console.ReadKey or Console.ForegroundColor. I think that Chad idea was to provide something simple like that.
Re: ColorD
On Monday, 28 May 2012 at 13:30:44 UTC, Robik wrote: On Monday, 28 May 2012 at 13:08:27 UTC, Marco Leise wrote: Am Sat, 26 May 2012 16:30:58 +0200 schrieb "Robik" : I would like to share with my new library written in D. As name may suggest (or not) it adds color to your console output, it works on both Linux and Windows platforms. I haven't seen any similar library for D language, so I decided to create this one. Source and examples(included in Readme file) can be found on GitHub repo: https://github.com/robik/ColorD Regards, Robik. +1
Re: etc.curl: Review ends today
On Thu, 01 Sep 2011 20:00:46 +0200, Jacob Carlborg wrote: > On 2011-09-01 18:28, jdrewsen wrote: >> Den 01-09-2011 06:43, David Nadlinger skrev: [snip] >> >>> Jonas, do you already have a revised version ready that could >>> immediately be voted upon? I recognize that quite a large number of >>> suggestions was raised, but as there are quite a few other components >>> currently waiting in the review queue, we want to make sure not to >>> introduce any avoidable delays while working through that list. >> >> I have done a lot of the changes but there are still quite some work >> left to do. Please go on with another review and I'll get back when I'm >> ready for a next round. >> >>> If not, I would propose to postpone the voting phase and start the >>> review for another component, e.g. David Simcha's std.regionallocator, >>> now. After Jonas had enough time to finish a version he considers fit >>> for inclusion into Phobos, I would suggest a short (one week) combined >>> review/vote period to decide on inclusion with the standard library. >> >> Sounds good to me. >> >> Thanks for running this review. >> >> /Jonas > > BTW, shouldn't etc.curl be std.net.curl now when we have a std.net > package. In general splitting Phobos into subpackages would be great idea. Now everything goes to root, if somebody implements more digest mechanisms we will have in root, std.md5, std.sha256, std.sha1, std.whirpool etc etc, std.digest.X looks way much better. Same goes with std.datetime, it really could be splitted into std.date.time, std.date.UTC etc etc :-D Sorry for off-topic :-p
Re: Just wanted to say
On Mon, 05 Sep 2011 18:38:01 +, Steve Teale wrote: > I've been using a recent version of D2 along with gtkD and Code::Blocks > to redo a quite complicated Windows GUI program I wrote back in the mid > 90s with the changes I've though of since then, in an Ubuntu > environment. > > This combination has definitely made me highly productive. D is a joy to > use, and so easy to read when I compare it with the numerous GTK+ > examples I've had to consult written in Python, PHP, C, and C++ > (particularly the latter - how did I use it all those years?). > > Thanks Walter et al. > > Steve Indeed, D + GtkD is real fun, never enjoyed gtk so much. But you can't forget about GtkD team. Thanks to them we got one solid GUI library :)
Re: switch()
On Sunday, 16 February 2014 at 15:43:31 UTC, Manu wrote:
So D offers great improvements to switch(), but there are a few
small
things I wonder about.
1.
case fall-through is not supported; explicit 'goto case n;' is
required.
With this in mind, 'break' is unnecessary. Why is it required?
It could be
implicit upon reaching the next case label, or a scope could be
used (with
support for omitting the scope for single statements as with
if).
It's really noisy, and annoying to write everywhere.
2.
'case 1, 3, 7, 8:' is awesome! ...but ranged cases have a
totally different
syntax: 'case 1: .. case 3:'
Why settle on that syntax? The inconsistency looks kinda silly
when they
appear together in code.
Surely it's possible to find a syntax that works without
repeating case and
':'?
It's also weird, because it seems that 'case n: .. case m:' is
inclusive of
m. This may be unexpected.
I'm not sure it's reasonable to use the '..' syntax in this
case for that
reason. '..' is an [) range, case ranges must be [] so that it
makes sense
when dealing with enum key ranges.
3.
Why is 'default' necessary? If I'm not switching on an
enumerated type,
then many values are meaningless. requiring an empty 'default:
break;' line
at the end is annoying and noisy.
I often find myself tempted to rewrite blocks of successive
if() logic
comparing integers against values/ranges, but it looks silly
since the
scope rules are not explicit, and 'default: break;' always
wastes an extra
line.
I like to reduce noise in my code, and these switch semantics
threaten to
simplify a lot of code, if not for these strange decisions
(purely for
legacy compliance?).
Let's consider an example:
Code like this:
int difficulty = -1;
if(e.note.note >= 60 && e.note.note < 72)
difficulty = 0;
else if(e.note.note >= 72 && e.note.note < 84)
difficulty = 1;
else if(e.note.note >= 84 && e.note.note < 96)
difficulty = 2;
else if(e.note.note >= 96 && e.note.note < 108)
difficulty = 3;
The repetition of e.note.note is annoying, and particular
choice of
comparisons are liable to result in out-by-ones. It's not nice
code to read.
Rewrites like this:
int difficulty;
switch(e.note.note)
{
case 60: .. case 71:
difficulty = 0;
break;
case 72: .. case 83:
difficulty = 1;
break;
case 84: .. case 95:
difficulty = 2;
break;
case 96: .. case 107:
difficulty = 3;
break;
default:
difficulty = -1;
break;
}
That's horrid, it's much longer! And there are pointless wasted
lines
everywhere.
The default case is a total waste, since -1 should just be
assigned when
initialising the variable above.
We can compact it a bit like this:
int difficulty;
switch(e.note.note)
{
case 60: .. case 71:
difficulty = 0; break;
case 72: .. case 83:
difficulty = 1; break;
case 84: .. case 95:
difficulty = 2; break;
case 96: .. case 107:
difficulty = 3; break;
default:
difficulty = -1; break;
}
But that's horrible too. It's not clear what vertical offset
the 'break'
statements shoudl appear at (I hate stacking up multiple
statements across
the same line!).
The the default case is still a waste.
Ideally:
int difficulty = -1;
switch(e.note.note)
{
case 60 .. 72:
difficulty = 0;
case 72 .. 84:
difficulty = 1;
case 84 .. 96:
difficulty = 2;
case 96 .. 108:
difficulty = 3;
}
'break's are unnecessary since fallthrough isn't allowed.
Proper numeric range could be supported (assuming [) intervals).
'default' case is unnecessary, and removed.
The switch and braces results in 3 extra lines, but I still
feel this level
of simplification results in code that is MUCH more readable
than the
sequence of if's I started with. It's super obvious what's
going on.
I have quite many blocks like this.
A great man once (actually, frequently) said "If it doesn't
look right, it
probably isn't".
Having also wrote a lot of switch statements in D I do mostly
agree on these points. I think this example 'case 1: .. case 3:'
is obvious. but I like 'case 1..3, 5, 6, 8, 9..10:' syntax better
(Pascal) see how much typing I save.
Break inside a switch should be rid of (Again Pascal) it's bloat.
Having a default does get a bit annoying I see a lot of these..
That being said it's nice having that extra safety.
Re: D in my trashbin
On Saturday, 25 October 2014 at 22:41:59 UTC, Kyoji Klyden wrote: On Saturday, 25 October 2014 at 22:17:35 UTC, Jkpl wrote: Just ask to Vlad. He seems to be the forum maintainer. He'll check the IP. Even if I'm not the OP, the message is clear: why the hell do you care about this ? DMD setup is fine. It works. dot. Haha, why would anyone go check your IP? Should we tell everyone who has trouble with DMD: "the setup is fine. It works. dot."? It has a very reassuring ring to it. Melts my troubles away. :P Once you're ready to take on "Hello World" or to show us your next great skit, feel free to post in D.Learn. But the setup is fine.. and when it isn't you can see from just how fast the community replies, that people do care, and will endeavour to fix it! There is also the option to use DMD without the installer, its not rocket science. In fact all this thread has really served is to prove just how much people do care for D.
Re: D's New GC and Object Allocation Pools
On Sunday, 26 October 2014 at 03:37:47 UTC, Maxime
Chevalier-Boisvert wrote:
Hello,
I was wondering if there have been updates regarding Andrei's
announcement that he would rewrite the D garbage collector. Is
there any kind of timeline for when a new version of the GC can
be expected?
I also wanted to ask if there was an implementation of an
object pool in the standard library. If not, I'm wondering what
the best way to implement this is. Is there any way to overload
new and destroy?
I was thinking of using the templated emplace operator from
std.conv to allocate class objects into a large flat array, and
to derive pool-allocated classes from a PoolObject base class.
This base class would contain linked list pointers to implement
a free list, as well as templated static methods to allocate
and free the objects. Any advice welcome.
For your object pool, why not just create functions, alloc and
free, instead of trying to override them - something like below
version (USE_GC)
{
import core.memory;
}
else
{
import core.stdc.stdlib: malloc, free;
}
struct MemPool
{
void* alloc(size_t size, bool usePool = true) nothrow
{
version (USE_GC) return GC.malloc(size);
else malloc(size);
}
void Free(void* p) nothrow
{
version (USE_GC) GC.free(p);
else free(p);
}
}
Re: Range of chars (narrow string ranges)
On Tuesday, 28 April 2015 at 23:15:40 UTC, H. S. Teoh wrote: On Tue, Apr 28, 2015 at 09:57:29PM +, Vladimir Panteleev via Digitalmars-d wrote: On Tuesday, 28 April 2015 at 16:48:48 UTC, Jonathan M Davis wrote: >But of course, we'd want to do the transition in a way that >didn't >result in silent behavioral changes that would break code, One proposal is to make char and dchar comparisons illegal (after all, they are comparing different things - an UTF-8 code unit with a code point, and even though in some cases this comparison makes sense, in many it doesn't). That would solve most silent breakages at the expense of more not-so-silent breakages. >And if we really wanted to do that, we could create a version >flag >that turned of autodecoding and version the changes in Phobos >appropriately to see what we got. Shameless self-promotion alert: An alternative is a GitHub fork. You can easily install and try out D forks with Digger, it's two commands: digger build master+jmdavis/phobos/noautodecode digger install Oooh, Jonathan has the code ready? Haha, maybe I'll start using that instead of git master! ;-) T I second that! If we all make the switch, perhaps Walter will too? :D
Re: Socket missing option: SO_REUSEPORT
On Wednesday, 21 December 2016 at 13:01:53 UTC, Benjiro wrote:
Just check the socket code and there is a small feature missing:
enum SocketOption: int
{
DEBUG =SO_DEBUG,/// Record
debugging information
BROADCAST =SO_BROADCAST,/// Allow
transmission of broadcast messages
REUSEADDR =SO_REUSEADDR,/// Allow local
reuse of address
There needs to be added:
REUSEPORT =SO_REUSEPORT,/// Allow local
reuse of the port
I don't think this needs weeks of discussion ;)
SO_REUSEPORT is not supported on Windows.
Re: Optional monitors suggestion
On Wednesday, 14 May 2014 at 11:06:43 UTC, Yuriy wrote: bearophile, good point. What do you think of the following solution: 1. Declaring member variable with __monitor identifier is disallowed. 2. class may be defined with @__monitor attribute, in which case a __monitor variable will be added to it's beginning. 3. Subclass of such class may again be defined with @__monitor attar, in which case it will be simply ignored, as it already inherits __monitor from super. These would be breaking changes. I see the benefit but... If the compiler recognizes the class using synchronized, it could use a little magic and add a monitor variable itself, this would not cause any breaking change.
Re: running code on the homepage
On Monday, 28 September 2015 at 14:15:18 UTC, ixid wrote: On Thursday, 17 September 2015 at 14:48:07 UTC, nazriel wrote: On Wednesday, 16 September 2015 at 20:52:08 UTC, Andrei Alexandrescu wrote: On 09/16/2015 09:49 AM, nazriel wrote: [...] That's great, thanks for doing this. What is the current status with regard to making the online compilation infrastructure publicly accessible and improvable? Ideally everything would be That's the plan. Currently I am working on upgrading both frontend and backend to be up-to-date with current requirements. I am also trying to integrate the look of dpaste.dzfl.pl to match the one on dlang.org so we could make dpaste part of the *.dlang.org fleet. Hi Damian, dpaste doesn't seem to produce any console output at the moment, I just get 'Result: Success / Return code: 0' and nothing from writeln. Thanks for the heads up! I am tinkering with the new backend and even though I double check if dlang.org examples still work I missed dpaste itself %) Anyways, fixed
